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Executive  Summary 


EXECUTIVE  SUMMARY 


The  security  protection  provided  by  Digital  Equipment 
Corporation's  VAX/ VMS  Version  4.3  operating  system  (with  "The 
VAX/ VMS  Systems  Dispatch"  article  95.5.8)  has  been  evaluated  by 
the  National  Computer  Security  Center  (NCSC).  The  security 
features  of  VAX/VMS  were  evaluated  against  the  requirements 
specified  by  the  DoD  Trusted  Computer  System  Evaluation  Criteria 
(the  Criteria),  CSC-STD-001-83 ,  dated  15  August  1983. 

The  NCSC  evaluation  team  has  determined  that  the  highest  class  at 
which  VAX/VMS  satisfies  all  the  specified  requirements  of  the 
Criteria  is  class  C2.  The  evaluated  hardware  set  includes  the 
following  stand-alone  processors:  11/725,  11/730,  11/750, 
11/751,  11/780,  11/782,  11/785,  8200,  8600,  and  8650  as  well  as 
Norden  Systems,  Inc.  MIL  VAX  I  and  II. 

Class  C2  systems  provide  a  more  finely  grained  discretionary 
access  control  than  Cl  systems,  making  users  individually 
accountable  for  their  actions  through  login  procedures,  auditing 
of  security-relevant  events,  and  resource  isolation. 

The  VAX/VMS  operating  system  is  a  general  purpose  time-sharing 
system  with  many  security  features.  VAX/ VMS  provides  hardware 
based  protection  through  a  hierarchical  four  mode  protection 
scheme.  This,  in  conduction  with  its  virtual  memory  protection 
capability,  provides  process  separation.  The  Access  Control  List 
(ACL)  mechanism  provides  discretionary  access  control. 


-  ix  - 
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INTRODUCTION 


In  September  1985,  the  National  Computer  Security  Center  (NCSC) 
began  a  formal  product  evaluation  of  VAX/ VMS  Version  4.2,  a 
Digital  Equipment  Corporation  product.  The  objective  of  this 
evaluation  was  to  rate  the  VAX/VMS  system  against  the  Criteria 
and  to  place  it  on  the  Evaluated  Products  List  (EPL).  In  April 
1986,  the  NCSC  and  Digital  mutually  agreed  to  evaluate  VAX/ VMS 
Version  4.3,  the  most  current  release  available.  This  report 
documents  the  results  of  the  evaluation  of  VAX/ VMS  Version  4.3 
released  by  Digital  in  December  1985. 

Material  for  this  report  was  gathered  by  the  NCSC  VAX/VMS 
evaluation  team  through  documentation  review,  interaction  with 
system  developers,  and  experience  using  VAX/ VMS  systems. 


Evaluation  Process  Overview 

The  Department  of  Defense  Computer  Security  Center  was 
established  in  January  1981  to  encourage  the  widespread 
availability  of  trusted  computer  systems  for  use  by  facilities 
processing  classified  or  other  sensitive  information.  In  August 
1985  the  name  of  the  organization  was  changed  to  the  National 
Computer  Security  Center.  In  order  to  assist  in  assessing  the 
degree  of  trust  one  could  place  in  a  given  computer  system,  the 
DoD  Trusted  Computer  System  Evaluation  Criteria  was  written.  The 
Criteria  establishes  specific  requirements  that  a  computer  system 
must  meet  in  order  to  achieve  a  predefined  level  of 
trustworthiness.  The  Criteria  levels  are  arranged  hierarchically 
into  four  major  divisions  of  protection,  each  with  certain 
security-relevant  characteristics.  These  divisions  are  in  turn 
subdivided  into  classes.  To  determine  the  division  and  class  at 
which  all  requirements  are  met  by  a  system,  the  system  must  be 
evaluated  against  the  Criteria  by  an  NCSC  evaluation  team. 

The  NCSC  performs  evaluations  of  computer  products  in  varying 
stages  of  development  from  initial  design  to  those  that  are 
commercially  available.  Product  evaluations  consist  of  a 
developmental  phase  and  a  formal  phase.  All  evaluations  begin 
with  the  developmental  phase.  The  primary  thrust  of  the 
developmental  phase  is  an  in-depth  examination  of  a 
manufacturer's  design  for  either  a  new  trusted  product  or  for 
security  enhancements  to  an  existing  product.  Since  the 
developmental  phase  is  based  on  design  documentation  and 
information  supplied  by  the  industry  source,  it  involves  no 
"hands  on"  use  of  the  system.  The  developmental  phase  results  in 
the  production  of  an  Initial  Product  Assessment  Report  (IPAR). 
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The  IPAR  documents  the  evaluation  team's  understanding  of  the 
system  based  on  the  information  presented  by  the  vendor.  Because 
the  IPAR  contains  proprietary  information,  distribution  is 
restricted  to  the  vendor  and  the  NCSC. 

Products  entering  the  formal  phase  must  be  complete  security 
systems.  In  addition,  the  release  being  evaluated  must  not 
undergo  any  additional  development.  The  formal  phase  is  an 
analysis  of  the  hardware  and  software  components  of  a  system,  all 
system  documentation,  and  a  mapping  of  the  security  features  and 
assurances  to  the  Criteria.  The  analysis  performed  during  the 
formal  phase  requires  "hands  on"  testing  (i.e. ,  functional 
testing  and,  if  applicable,  penetration  testing).  The  formal 
phase  results  in  the  production  of  a  final  report  and  an 
Evaluated  Products  List  entry.  The  final  report  is  a  summary  of 
the  evaluation  and  includes  the  EPL  rating  which  indicates  the 
final  class  at  which  the  product  successfully  met  all  Criteria 
requirements  in  terms  of  both  features  and  assurances.  The  final 
report  and  EPL  entry  are  made  public. 


Document  Organization 

This  report  consists  of  five  major  sections  and  five  appendices. 
Section  1  is  an  introduction.  Section  2  provides  a  general 
overview  of  the  VAX  system  architecture.  Section  3  provides  a 
mapping  between  the  requirements  specified  in  the  Criteria  and 
the  VAX/VMS  features  that  fulfill  those  requirements.  Section  4 
describes  an  additional  feature  in  the  VAX/VMS  system  that 
satisfies  a  requirement  at  a  class  higher  than  the  rated  class. 
Section  5  provides  an  opportunity  for  the  evaluation  team  to 
provide  comments  about  the  system. 

Appendix  A  lists  the  evaluated  hardware  components.  Appendix  B 
lists  the  evaluated  software  components.  Appendix  C  lists  the 
privileges  in  VAX/ VMS.  Appendix  D  lists  the  acronyms  and  their 
expansions  used  in  this  report.  Appendix  E  lists  the  references 
used  in  the  writing  of  this  report. 
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SYSTEM  OVERVIEW 


Introduction 

VAX  is  a  virtual  address  extension  of  the  PDP-11  architecture. 
The  system  is  distinguished  by  a  32-bit  architecture,  a  memory 
management  and  protection  mechanism,  and  a  virtual  memory 
operating  system  which  provides  a  large  program  address  space. 

The  VAX  product  line  maintains  a  consistent  architecture  across 
processor  lines  and  between  microcode  updates.  The  VAX  hardware 
line  consists  of  many  different  implementations  of  the  VAX 
architecture . 

The  VAX  architecture  is  defined  by  "Digital  Equipment  Corporation 
Standard  032"  (see  page  E-1,  "References”).  This  docvunent 
defines  the  VAX  architecture.  It  provides  a  complete  description 
of  the  VAX  central  processor  hardware  as  seen  by  machine  language 
programs,  and  applies  to  all  software  written  for  the  VAX 
processors ,  all  VAX  central  processor  hardware ,  and  aJ 1 
closely-coupled  VAX  hardware  peripherals.  Thus,  the  consistei^t 
VAX  architecture  supports  the  portability  of  software  across 
different  hardware  implementations. 

The  most  important  method  of  verifying  that  a  new  VAX  system,  or 
an  update  to  an  existing  system,  meets  the  architectural 
definition  presented  in  "Digital  Equipment  Corporation  Standard 
032"  is  the  use  of  a  specialized  tool.  The  tool's  purpose  is  to 
verify  the  correct  operation  of  the  combination  of  instructions 
and  operands  defined  by  "Digital  Equipment  Corporation  Standard 
032".  Conformance  to  this  standard  is  tested  by  running  test 
cases  in  each  instruction  group  without  any  errors. 

This  architectural  reference  also  describes  the  general 
methodology  of  performing  virtual  memory  address  translation  and 
processor  state  transition,  and  defines  a  process'  structure. 
The  reference,  however,  does  not  identify  any  constraints  or 
guidelines  with  respect  to  I/O.  This  implies  that  systems  with 
vast  differences  in  bus  system  speeds  and  bandwidths  can  still 
meet  the  architectural  standard.  The  security-relevant  aspect  of 
I/O  is  that  each  implementation  of  the  architecture  (processor 
line)  treats  its  own  I/O  subsystem  in  a  uniform  manner.  Since 
this  is  the  case  among  the  VAX  family  of  processors,  the  only 
remaining  relevant  issue  is  the  bandwidth  of  the  subsystem. 
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However ,  bandwidth  and  covert  channels  are  not  a  concern  at  the 
C2  level.  (For  a  complete  list  of  the  evaluated  hardware  set, 
see  page  A-1,  "Evaluated  Hardware  Components".) 

The  VAX  family  architecture  is  characterized  by  a  set  of  304 
instructions.  Those  instructions  that  are  specific  to 
specialized  portions  of  the  VAX  architecture  (memory  management, 
interrupts  and  exceptions,  process  dispatching,  and  process 
registers)  are  used  by  privileged  software.  In  comparison  with 
the  PDP-11  architecture,  the  VAX  architecture  offers  a  wide  range 
of  data  types,  nine  addressing  modes,  full  demand  paging  memory 
management  and  a  4  gigabyte  virtual  address  space. 

VAX/ VMS  (Virtual  Address  extension/ Virtual  Memory  System)  is  a 
multiuser,  multifunction  virtual  memory  operating  system  that 
supports  multiple  languages,  an  interactive  command  interface, 
and  program  development  tools.  The  operating  system  performs 
process-oriented  paging  that  allows  execution  of  programs  that 
may  be  larger  than  the  physical  memory  allocated  to  them.  Paging 
is  handled  automatically  by  the  system. 

The  memory  management  facilities  provided  by  VAX/VMS  encompass 
both  the  memory  protection  and  memory  mapping  mechanisms  of  VAX. 
Memory  management  software  maintains  tables  of  mapping 
information  (page  tables)  that  keep  track  of  where  each  512  byte 
virtual  page  is  located  in  physical  memory.  The  CPU  uses  this 
mapping  information  when  it  translates  virtual  addresses  to 
physical  addresses. 

Memory  management  also  provides  page  protection  between  processes 
since  the  process  address  of  one  process  is  not  accessible  to 
code  running  in  the  context  of  another  process.  When  such 
accessibility  is  desired  to  share  common  routines  or  data,  VMS 
provides  controlled  access  through  global  sections  (see  page  19, 
"Global  Sections"). 

In  addition,  four  hierarchical  access  modes  provide  memory  access 
control.  Any  location  accessible  to  one  mode  is  also  accessible 
to  higher  privileged  modes.  (For  an  explanation  of  how  the  four 
access  modes  provide  memory  access  protection  see  page  9,  "Memory 
Management " . ) 

A  process  can  prevent  pages  from  being  paged  out  of  its  working 
set.  With  sufficient  privilege,  it  can  prevent  its  entire 
working  set  from  being  swapped  out,  to  optimize  program 
performance  for  real-time  applications  or  interactive 
environments . 
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VAX/VMS  schedules  GPU  time  and  memory  residency  on  a  priority 
basis.  Scheduling  rotates  among  processes  of  the  same  priority. 
The  scheduler  adjusts  the  priority  of  processes  assigned  to  one 
of  the  low  16  priorities  to  improve  responsiveness  and  to  overlap 
I/O  and  computation.  Real-time  processes  can  be  placed  in  one  of 
the  top  16  scheduling  priorities,  in  which  case  the  scheduler 
does  not  alter  their  priority  and  does  not  preempt  them. 
Therefore.,  real-time  processes  do  not  compete  with  lower  priority 
processes  for  scheduling  services.  Their  priorities  can  be 
adjusted  by  the  system  manager  or  an  appropriately  privileged 
user . 

Data  management  is  provided  by  VAX/VMS  through  a  file  and  record 
management  facility  that  allows  the  user  to  create,  access,  and 
maintain  data  files  and  records  within  files  with  full 
protection.  The  record  management  services  (RMS)  handles 
sequential,  relative,  and  multikey  indexed  files.  These  files 
may  have  fixed  or  variable  length  records. 

The  VAX/VMS  operating  system  supports  the  Files-11  On-Disk 
Structure  Level  2  (ODS-2),  which  provides  the  facilities  for  file 
creation,  extension,  and  deletion  with  owner-specified 
protections  and  hierarchical  directories. 


Processor  State 

The  VAX  family  CPU  provides  sixteen  32-bit  general  registers 
which  can  be  used  for  temporary  storage,  or  as  accumulators, 
index  registers,  and  base  registers.  Registers  RO  through  Rll 
can  be  used  as  general  purpose  registers.  The  remaining  four 
registers  take  on  special  significance  depending  on  the 
instruction  being  executed:  Register  12  (the  Argument  Pointer); 
Register  13  (the  Frame  Pointer);  Register  14  (the  Stack  Pointer); 
and  Register  15  (the  Program  Counter). 

The  CPU  state  consists  of  that  portion  of  a  process'  state  which, 
while  the  process  is  executing,  is  stored  in  processor  registers 
rather  than  memory.  The  processor  state  includes  the  16  general 
purpose  registers,  a  32-bit  processor  status  longword  (PSD,  and 
privileged  internal  processor  registers  (IPR). 

The  process  status  longword  (PSL)  is  a  longword  (32-bit) 
consisting  of  the  privileged  processor  status  concatenated  with 
the  processor  status  word  (PSW).  The  PSW  contains  the  condition 
codes  that  provide  information  on  the  results  produced  by 
previous  instructions  and  the  exception  enables  which  control  the 
processor  action  on  certain  exception  conditions. 
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The  privileged  internal  processor  register  space  provides  access 
to  different  types  of  CPU  control  and  status  registers  (e.g.,  the 
memory  management  base  registers,  parts  of  the  PSL,  and  the 
multiple  stack  pointers).  These  registers  are  explicitly 
accessible  only  by  the  Move_To_Processor_Register  (MTPR)  and 
Move_From_Processor_Register  (MFPR)  instructions  which  require 
kernel  mode  (see  page  9,  "Memory  Management")  privilege. 


User  Process 

An  image  is  an  executable  program  which  is  created  by  translating 
source  language  modules  into  object  modules  and  then  linking  the 
object  modules  together.  When  a  user  initiates  image  execution, 
the  image  activator,  part  of  the  executive,  sets  up  the  process 
page  tables  to  point  to  the  appropriate  sections  of  the  image 
file.  VAX/ VMS  uses  the  same  paging  mechanism  that  implements  its 
virtual  memory  support  to  read  image  pages  into  physical  memory 
as  they  are  needed  to  execute  it. 

The  environment  in  which  an  image  executes  is  called  its  context. 
The  complete  context  of  an  image  includes  not  only  the  state  of 
its  execution  at  any  one  time  (hardware  context)  but  also  the 
definition  of  its  resource  allocation  privileges  and  resource 
quotas.  Certain  software  information,  including  some  key 
addresses  and  some  software  data  structures,  comprise  the 
software  context.  An  image  executing  in  its  context  is  called  a 
process . 

A  process  is  the  basic  schedulable  entity  in  the  VAX/ VMS  system. 
A  process  consists  of  a  virtual  address  space  and  hardware  and 
software  contexts.  The  hardware  context  of  a  process  is  defined 
by  values  that  are  loaded  into  processor  registers  when  a  process 
is  scheduled  for  execution.  When  a  process  is  not  being 
executed,  its  hardware  context  is  stored  in  the  hardware  process 
control  block  (hardware  PCB).  The  hardware  PCB  is  maintained  by 
a  software  structure  known  as  the  process  header  (PHD).  The  act 
of  saving  the  contents  of  the  processor  registers  in  the  hardware 
PCB  of  the  currently  executing  process  and  loading  the  new  set  of 
context  from  another  hardware  PCB  is  called  context  switching. 
The  context  switching  operation  uses  two  kernel  instructions: 
the  Save_Process_Context  (SVPCTX)  and  Load_Process_Context 
(LDPCTX).  The  software  context  for  each  process  is  maintained  in 
the  software  process  control  block  (software  PCB). 

A  job  is  defined  to  be  the  collection  of  subprocesses  that  has  a 
common  root  process.  The  concept  of  a  job  exists  solely  for  the 
purpose  of  sharing  resources. 
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Hardware  Content 

The  hardware  context  consists  of  copies  of  the  general-purpose 
registers,  the  four  per-process  stack  pointers,  the  program 
counter  (PC),  the  processor  status  longword  (PSL),  and  the 
process-specific  processor  registers  including  the  memory 
management  registers  (see  page  9,  "Memory  Management")  and  the 
asynchronous  system  trap  (AST)  level  register  implementing  the 
software  interrupt  scheme.  The  hardware  context  is  stored  in  the 
hardware  process  control  block  that  is  used  primarily  when  a 
process  is  removed  from  or  selected  for  execution. 

There  is  one  per-process  stack  for  each  of  the  four  access  modes. 
Any  code  that  executes  on  behalf  of  a  process  uses  one  of  that 
process'  four  stacks. 


Software  Context 

The  software  context  of  a  process  consists  of  all  the  data 
required  by  the  operating  system  to  make  scheduling  and  other 
control  decisions  about  a  process.  This  information  includes  the 
process  priority,  scheduling  state,  process  privileges,  resource 
quotas,  process  name  and  process  ID. 

The  software  PCB  stores  process  data  that  must  be  constantly 
resident  in  memory.  This  includes  the  software  priority  of  the 
process,  its  unique  process  identification  (PID),  the  current 
process'  scheduling  state  and  some  resource  quotas.  Those 
resource  quotas  that  are  shared  among  all  processes  in  the  same 
Job  are  stored  in  the  job  information  block  (JIB).  A  JIB  is  a 
collection  of  images  in  the  same  process. 

The  process  header  data  structure  contains  information  about  the 
process  which  does  not  have  to  be  permanently  memory  resident 
(swappable  process  context).  This  information  is  required  only 
when  the  process  is  resident  and  is  used  by  memory  management 
when  a  page  fault  occurs.  Moreover,  this  data  is  used  by  the 
swapper  when  the  process  is  removed  from  memory  (outswapped)  or 
brought  into  memory  (inswapped).  The  hardware  PCB,  which 
contains  the  hardware  context  of  the  process,  is  also  part  of  the 
process  header.  Whenever  the  process  is  resident,  the  data  in 
the  process  header  is  available  to  appropriately  privileged  code. 

Other  process-specific  information  is  stored  in  the  control 
region  of  the  process  virtual  address  space  (PI).  This 
information  is  only  accessible  when  the  process  is  executing. 
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Information  stored  in  PI  space  includes:  exception  dispatching 
information,  RMS  data  tables,  and  information  about  the  image 
currently  executing. 


Process  Virtual  Address  Space 

The  basic  addressable  unit  in  VAX  is  the  8-bit  byte.  Virtual 
addresses  are  32  bits  long;  resulting  in  the  virtual  address 
space  of  "2  to  the  32"  bytes.  The  virtual  address  space  of  a 
process  is  described  by  the  process  PO  and  PI  page  tables.  These 
are  stored  in  the  high  address  end  of  the  process  header.  A 
programmer  uses  a  32-bit  virtual  address  to  identify  a  byte 
location.  This  address  is  called  a  virtual  address  as  it  is  not 
the  real  address  of  a  physical  memory  location.  It  is  translated 
into  a  real  address  by  the  processor  under  operating  system 
control.  A  virtual  address  is  net  a  unique  address  of  a  location 
in  memory,  as  are  physical  memory  addresses. 

The  set  of  all  possible  32-bit  virtual  addresses  is  called 
virtual  address  space.  This  address  space  is  equally  divided 
into  process  space  (PO,  PI)  and  system  space  (SO,  SI).  A  process 
can  not  represent  virtual  addresses  in  any  process  space  but  its 
own.  Therefore,  code  and  data  belonging  to  a  process  are 
automatically  protected  from  other  processes  in  the  system. 

The  process  space  is  altered  when  an  image  is  initially 
activated,  during  image  execution  through  selected  system 
services,  and  when  an  image  terminates.  The  process  page  tables 
reside  in  system  virtual  address  space  and  are  described  by 
entries  in  the  the  system  page  table.  The  page  table  entry  (PTE) 
is  the  longword  used  to  translate  virtual  addresses  to  physical 
ones.  Unlike  other  portions  of  the  process  header,  the  process 
page  tables  are  themselves  pageable  and  are  faulted  into  the 
process'  working  set  only  when  they  are  needed. 

Process  space  is  divided  into  two  equal  regions :  program  region 
and  control  region.  The  addresses  in  the  program  region  are  used 
to  identify  the  location  of  image  code  and  data.  Addresses  in 
the  control  region  are  used  to  refer  to  stacks  and  other 
temporary  program  image  and  permanent  process  control  information 
maintained  by  the  operating  system  on  behalf  of  the  process. 

Addresses  in  the  remaining  half  of  the  virtual  address  space  are 
used  to  refer  to  locations  maintained  and  protected  by  the 
operating  system.  This  space  is  refered  to  as  system  space.  The 
operating  system  assigns  specific  meanings  to  addresses  in  system 
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space;  the  same  meaning  for  every  process,  independent  of 
context .  Locations  referred  to  by  system  space  addresses  are 
protected  from  access  by  user  images. 

System  space  is  also  divided  into  two  equal  regions.  Addresses 
in  the  first  region  (system  region)  are  used  for  linkages  to 
operating  system  service  procedures,  for  memory  management  data, 
and  for  I/O  processing  routines.  The  second  region  of  system 
space  is  currently  unused. 


Memory  Management 

The  processor's  memory  management  includes  four  hierarchical 
processor  access  modes  that  are  used  to  provide  read/write  page 
protection  between  user  software  and-  system  software.  The  access 
modes  from  most  privileged  to  least  are:  kernel,  executive, 
supervisor,  and  user.  Kernel  mode  is  used  by  the  kernel  for  page 
management,  scheduling,  and  I/O  drivers.  Executive  mode  is  used 
for  many  of  the  operating  system  service  calls,  including  RMS. 
Other  services,  such  as  command  interpretation,  are  run  in 
supervisor  mode.  Finally,  user  mode  is  used  for  user  level  code, 
utilities,  compilers,  debuggers,  etc.  Privileged  data  structures 
can  be  protected  by  not  allowing  read  or  write  access  to 
non-privileged  users.  A  read  or  write  permission  at  a  less 
privileged  mode  is  automatically  granted  at  a  more  privileged 
mode . 

Memory  protection  is  the  function  of  validating  whether  a 
particular  type  of  memory  access  is  allowed  to  a  particular  page. 
Access  to  each  page  is  controlled  by  a  protection  code  that 
specifies  for  each  access  mode  whether  or  not  read  or  write 
references  are  allowed.  Additionally,  each  address  is  checked  to 
make  sure  that  it  lies  within  the  PO,  PI,  or  system  region. 
Attempts  to  access  virtual  addresses  outside  these  bounds  cause  a 
length-violation  fault.  (For  an  explanation  of  how  access  mode 
switching  occurs  see  page  10,  "Mode  Switching  Instructions".) 

Memory  management  registers  are  used  to  perform  address 
translation,  enable  mapping,  and  to  capture  errors  from  memory 
management . 

Every  page  in  the  virtual  address  space  is  proteoteu  according  to 
its  use.  Even  though  all  of  the  system  space  is  shared,  a 
program  may  be  prevented  from  reading  or  modifying  it .  For 
example,  in  system  space,  scheduling  queues  are  highly  protected 
whereas  library  routines  would  be  executable  by  code  at  any 
access  mode. 
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Mode  Switching  Instructions 

There  are  four  instructions  that  allow  a  program  to  change  its 
access  mode  to  the  same  or  a  more  privileged  mode  and  transfer 
control  to  a  service  dispatcher  for  the  new  mode  using  a  standard 
CALL  instruction.  These  are;  Change_Mode_To_Kernel  (CHMK), 
Change_Mode_To_Executive  (CHME),  Change_Mode_To_Supervisor 
(CHMS),  and  Change_Mode_To_User  (CHMU). 

These  instructions  provide  the  normal  mechanism  for  less 
privileged  code  to  call  more  privileged  code.  When  the  mode 
transition  takes  place,  the  previous  mode  is  saved  in  the 
Previous  Mode  field  of  the  PSL,  thus  allowing  the  more  privileged 
code  to  determine  the  privilege  of  its  caller. 

In  addition,  there  are  two  instructions  which  are  used  in 
conjunction  with  the  above  privileged  instructions.  The 
Probe _Read  (PROBER)  and  Probe_Write  (PROBEW)  instructions  allow 
privileged  services  to  check  addresses  passed  as  parameters.  The 
service  routine  always  verifies  that  its  less  privileged  caller 
could  have  directly  referenced  the  address  passed  as  parameters. 
Specifically,  the  PROBE  instructions  check  the  read  and  write 
accessibility  of  the  first  and  last  byte  specified. 

The  operating  system's  privileged  service  procedures  and 
interrupt  and  exception  service  routines  exit  using  the 
Return_From_Exception_Or_Interrupt  (REI)  instruction.  REI  is  the 
only  way  to  decrease  the  privilege  of  the  processor's  access 
mode.  The  REI  is  used  to  restore  the  PC  and  the  processor  state 
to  resume  the  process  at  the  point  where  it  was  interrupted. 


Input /Output 

The  I/O  subsystem  consists  of  device  drivers  and  their  associated 
data  structures,  device  independent  routines  within  the 
executive,  and  several  system  services.  The  most  important 
system  service  is  the  $QIO  request,  the  I/O  request  that  is 
issued  by  all  outer  layers  of  the  system.  I/O  services  perform 
input  and  output  operations  directly  to  a  device  driver,  rather 
than  through  the  file  handling  provided  by  RMS .  The  VAX 
architecture  has  no  special  instructions  for  input  and  output . 
Instead,  inputs  and  outputs  are  performed  by  reads  and  writes  of 
special  physical  memory  addresses  called  CSRs  (Control  and  Status 
Registers)  and  DBRs  (Data  Buffer  Registers).  Thus,  the  memory 
protection  scheme  also  provides  the  protection  of  input  and 
output . 
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EVALUATION  AS  A  C2  SYSTEM 


EigcjS-tiQBary  Access  Control 
Requj regent 

The  TCB  shall  define  and  control  access  between  named 
users  and  named  objects  (e.g.,  files  and  programs)  in 
the  ADP  system.  The  enforcement  mechanism  (e.g., 
self /group/public  controls,  access  control  lists)  shall 
allow  users  to  specify  and  control  sharing  of  those 
objects  by  named  individuals,  or  defined  groups  of 
individuals,  or  both.  The  discretionary  access  control 
mechanism  shall,  either  by  explicit  user  action  or  by 
default ,  provide  that  objects  are  protected  from 
unauthorized  access.  These  access  controls  shall  be 
capable  of  including  or  excluding  access  to  the 
granularity  of  a  single  user.  Access  permission  to  an 
object  by  users  not  already  possessing  access 
permission  shall  only  be  assigned  by  authorized  users. 


Applicable  Features 

There  are  several  components  in  VAX /VMS  that  provide 
discretionary  access  controls.  These  components  are  Access 
Control  Lists,  UIC  (User  Identification  Code)  based  protection, 
privileges,  and  default  protection  mechanisms.  The  set  of 
objects  and  their  protection  mechanisms  that  have  been  identified 
by  the  VAX/VMS  evaluation  team  as  being  security-relevant  will  be 
discussed. 


Identifiers 

An  identifier  is  a  way  to  represent  a  user  or  a  group  of  users  in 
the  system.  There  are  three  types  of  identifiers:  UIC 
Identifiers,  General  Identifiers,  and  System  Identifiers. 


UIC  Identifier 

A  UIC  has  two  common  formats:  numeric  and  alphanumeric.  A  UIC 
in  numeric  representation  contains  a  group  number  and  member 
number.  A  UIC  in  alphanumeric  format  contains  a  member  name  and. 
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optionally,  a  group  name.  The  member  part  of  an  alphanumeric  UIC 
is  equated  to  both  the  group  and  member  parts  of  a  numeric  UIC  in 
the  system  rights  database.  Therefore,  member  names  must  be 
unique.  An  example  of  a  UIC  would  be  [GROUPl,  JONES],  where 
JONES  is  a  member  of  GROUPl . 


General  Identifiers 

A  General  Identifier  is  a  convienent  way  for  the  system  manager 
to  identify  classes  of  users.  They  are  created  by  adding  the 
desired  Identifier  alphanumeric  string  to  the  Rights  database, 
with  the  list  of  users  that  are  to  be  associated  with  that 
General  Identifier.  An  example  might  be  BIOLOGY201  that  contains 
a  list  of  all  students  enrolled  in  that  class. 


System  Identifiers 

The  System  Identifiers  are  automatically  created  when  the  Rights 
database  is  created.  System  Identifiers  describe  particular 
types  or  classes  of  users.  They  are  used  to  restrict  the  way  in 
which  a  user  can  log  into  the  system  and  can  also  be  used  in  an 
Access  Control  Entry  (ACE)  to  restrict  access  to  an  object  based 
upon  how  the  user  has  logged  in  to  the  system.  VAX/ VMS  has  six 
predefined  System  Identifiers:  BATCH,  NETWORK,  INTERACTIVE, 
LOCAL,  DIALUP,  and  REMOTE.  An  example  Of  a  System  Identifier  is 
BATCH.  All  Batch  jobs  carry  the  BATCH  Identifier. 


Access  Control  Lists 

VAX/VMS  supports  Access  Control  Lists  (ACLs)  for  five  types  of 
objects:  files,  directories,  devices,  global  sections,  and 
logical  name  tables.  An  ACL  consists  of  a  series  of  Access 
Control  List  Entries  (ACEs).  There  are  three  different  types  of 
ACEs:  Identifier  ACEs,  Default  Protection  ACEs,  and  Alarm  ACEs. 

The  Identifier  ACE  controls  the  type  of  access  allowed  to 
specific  users  based  on  the  user's  identification;  it  specifies 
Read,  Write,  Execute,  Delete,  Control,  or  Null  access  rights  to 
an  object  for  the  specified  Identifiers. 

The  Default  Protection  ACE  is  only  for  directories.  All  files 
created  under  a  directory  with  a  Default  Protection  ACE  will  have 
their  protection  set  to  whatever  is  specified  by  the  Default  ACE. 
The  effect  of  setting  a  default  ACE  occurs  only  on  files  created 
after  the  Default  ACE  has  been  created.  Any  files  that  existed 
before  the  Default  ACE  was  created  will  not  be  affected. 
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(However,  the  current  protection  could  be  changed  on  all  existing 
files  by  using  the  SET  PROTECTION  command,  so  as  to  conform  with 
the  Default  ACE . ) 

The  Alarm  ACE  specifies  whether  auditing  is  to  be  performed  and 
what  type  of  accesses  should  be  audited.  Alarm  ACEs  can  be 
created  on  a  per  object  basis  for  files  and  directories.  For 
auditing  to  occur,  a  privileged  user  must  enable  the  alarm 
auditing  mechanism  (see  page  25,  "Audit"). 

An  access  control  list  may  be  added  to  the  above  listed  five 
types  of  objects  by  use  of  a  system  service  call  ($CHANGE_ACL) ,  a 
DCL  command  (SET  ACL/OBJECT=) ,  or  the  ACL  editor  (EDIT/ACL). 
There  are  also  commands  for  setting  up  default  ACLs  and 
displaying  ACLs,  as  well  as  some  helpful  commands  for  duplicating 
ACLs  (SET  ACL/LIKE=).  The  search  order  for  the  ACL  list  is  from 
first  ACE  to  last  stopping  at  the  first  match.  The  user  is 
reponsible  for  ordering  ACEs  correctly  -  usually  from  the  most 
restrictive  to  the  most  general. 


Identifier  ACE 

Identifier  ACEs  are  used  to  define  which  access  rights  are 
allowed  to  Identifiers.  An  Identifier  ACE  specifies  the  access 
rights  that  are  available  to  a  specific  UIC:  the  UIC  must  conform 
to  the  valid  UIC  format  as  described  on  page  11,  "UIC 
Identifier" . 

An  Identifier  ACE  can  have  one  or  more  of  the  following  options: 
DEFAULT.  PROTECTED.  NOPROPOGATE.  and  NONE.  The  options  field 
controls  whether  an  ACE  is  propagated  or  deleted. 

The  DEFAULT  option  is  only  valid  for  directories  and  is  used  to 
indicate  that  the  ACE  is  to  be  included  in  the  ACL  of  all  files 
created  within  the  directory  -  it  is  not  used  in  determining 
directory  protection.  The  PROTECTED  option  indicates  that  the 
ACE  will  be  preserved  even  when  an  attempt  is  made  to  delete  the 
ACL.  The  NOPROPOGATE  option  indicates  that  the  ACE  is  not  to  be 
propagated  to  later  versions  of  the  file  or  from  a  parent 
directory  to  a  newly  created  file  in  that  directory.  The  NONE 
option  specifies  that  there  are  no  options  for  the  ACE.  If  the 
NONE  option  is  used  in  conjunction  with  any  other  options,  the 
other  options  take  precedence.  The  main  purpose  of  the  NONE 
option  is  for  aesthetics  and  uniformity  of  the  command  language. 
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For  each  Identifier  ACE  the  Access  field  of  the  ACE  is  used  to 
define  the  access  rights  that  are  associated  with  the  Identifier. 
The  access  rights  can  be  set  to  one  or  more  of  the  following: 
READ.  WRITE,  EXECUTE.  DELETE.  CONTROL,  and  NONE. 

READ  access  allows  all  users  associated  with  the  Identifier  to 
read  a  file,  logical  name  table,  global  section,  or  disk,  or 
allocate  a  device.  WRITE  access  implies  that  the  users  can  read 
or  write.  EXECUTE  access  allows  users  to  execute  an  image  file, 
DCL  procedure  file,  or  to  look  up  entries  in  a  directory  without 
using  the  wildcard  characters  (special  symbols  which  indicate 
"any"  or  "all"  for  a  given  field).  DELETE  allows  for  deletion  of 
a  file.  CONTROL  access  grants  the  same  privileges  as  the  owner 
of  the  object  and  NONE  grants  a  user  no  access  to  the  object. 


Default  Protection  ACE 

The  Default  ACE  is  used  to  ensure  that  a  particular  UlC-based 
protection  (a  protection  bit  mask  scheme;  see  page  15,  "UIC-Based 
Protection")  is  propagated  throughout  a  directory  tree.  Default 
protection  ACEs  can  only  be  applied  to  directories.  This  ACE 
allows  for  the  protection  of  a  particular  directory  tree  which  is 
different  than  that  applied  to  the  default  protections  applied  to 
directories  in  general.  The  protection  mask  field(s)  of  the 
Default  ACE  are  the  same  as  the  UlC-based  protection  with  the 
user  categories:  SYSTEM,  OWNER,  GROUP  and  WORLD,  and  the  access 
categories:  READ,  WRITE.  EXECUTE,  and  DELETE. 

It  is  important  to  note  that  a  user  can  not  rely  totally  on 
directory  protection  to  protect  contained  files.  It  is  possible 
to  open  a  file  (by  the  use  of  file  identification  numbers  rather 
than  path  names)  which  a  user  has  access  to  even  though  the 
containing  directory  denies  access  (see  "Guide  to  VAX/ VMS  System 
Security" ) . 


Alarm  ACE 

The  Alarm  ACE  is  used  to  specify  tnat  an  alarm  message  is  to  be 
sent  to  the  Security  Administrator's  terminal  (or  audit  log)  if 
the  specified  event  takes  place.  An  Alarm  ACE  applies  only  to 
disk  files  or  directories  and  only  functions  when  the  Security 
Administrator  has  enabled  auditing.  The  Alarm  ACE  can  be  set 
with  one  or  more  of  the  following  options:  DEFAULT,  PROTECTED, 
NOPROPOGATE,  and  NONE. 
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The  DEFAULT  Option  can  only  be  applied  to  directories  and  is  used 
to  indicate  that  the  Alarm  ACE  is  to  be  included  in  the  ACL  of 
any  file  created  within  the  directory.  The  PROTECTED  option 
indicates  that  the  Alarm  ACE  is  to  be  preserved  even  when  an 
attempt  is  made  to  delete  the  ACL.  The  NOPROPOGATE  option  is 
used  to  indicate  that  the  Alarm  ACE  is  not  copied  to  later 
versions  of  the  file.  The  NONE  option  indicates  that  no  options 
are  set  for  the  Alarm  ACE.  If  this  option  is  used  in  conjunction 
with  any  other  options,  the  other  options  take  precedence  (see 
page  25.  "Audit"). 


UIC-Based  Protection 

UlC-based  protection  is  determined  by  an  owner  UIC  (see  page  11, 
"UIC  Identifier")  and  protection  code.  UlC-based  protection 
mediates  access  to  the  following  objects  in  the  system;  files, 
directories,  volumes,  devices,  mailboxes,  common  event  flag 
clusters,  global  sections,  logical  name  tables,  and  queues.  A 
volume  is  the  medium  which  is  logically  mounted  on  a  device.  For 
example,  disk  packs  and  reels  of  magnetic  tape  are  called  volumes 
when  they  are  mounted  on  disk  and  tape  drives.  For  disk  volumes, 
the  system  provides  protection  at  the  file,  directory,  and  volume 
levels.  For  tape  volumes,  the  system  provides  protection  only  at 
the  volume  level.  For  further  information,  see  the  "Guide  to 
VAX/VMS  Disk  and  Tape  Operations" . 

When  a  user  attempts  to  access  a  file  or  volume,  the  user's  UIC 
is  compared  to  the  owner  UIC  of  the  object.  Depending  on  the 
relationship  of  the  UICs,  the  user  falls  into  one  or  more  of  the 
following  four  categories  (see  "Guide  to  VAX/VMS  System 
Security" ) : 

1 .  SYSTEM 

A  user  is  granted  the  access  rights  specified  in  the 
system  category  of  the  UlC-based  protection  code 
associated  with  the  object  if  one  of  the  following  is 
t  rue : 

a.  The  user  has  system  privilege  (SYSPRV). 

b.  The  user  has  a  group  number  between  1  and  10  (octal). 
These  group  numbers  are  generally  for  system  managers, 
security  managers,  system  programmers,  operators  and 
other  privileged  users.  The  range  of  numbers  used  can  be 
changed  by  the  system  manager  during  SYSGEN.  Users  given 
these  group  numbers  are  implicitly  given  system 
privileges . 
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c.  The  user  has  group  privilege  (GRPPRV)  and  the  group 
field  of  the  user's  UIC  matches  the  group  field  of  the 
owner's  UIC. 

d.  The  user  is  the  owner  of  the  volume  of  the  disk  where 
the  file  is  located.  The  owner  UIC  of  the  volume  is  set 
at  the  time  the  disk  is  initialized.  This  requires 
volume  privilege  (VOLPRO). 

2 .  OWNER 

A  user  is  granted  the  access  rights  specified  in  the 
owner  category  of  the  UlC-based  protection  code 
associated  with  the  object  if  the  user ' s  UIC  matches  the 
object's  UIC. 

3 .  GROUP 

A  user  is  granted  the  access  rights  specified  in  the 
group  category  of  the  UlC-based  protection  code 
associated  with  the  object  if  the  group  field  of  the 
user's  UIC  matches  the  group  field  of  object's  UIC. 

4 .  WORLD 

Any  user  gains  the  access  rights  designated  in  the 
UlC-based  protection  code  associated  with  the  object. 

Each  of  these  categories  of  users  can  be  granted  or  denied  any  of 
the  following  types  of  access:  READ,  WRITE,  EXECUTE,  and  DELETE. 
A  protection  code  describes  the  categories  of  users  who  have 
access  to  an  object  and  the  type  of  access  that  they  have.  For 
example,  the  file  protection  code: 

SYSTEM :RWED,  OWNER :RWED,  GROUP: RE,  WORLD: RE 

specifies  that  users  in  the  SYSTEM  and  OWNER  categories  have 
READ,  WRITE,  EXECUTE,  and  DELETE  access.  Users  in  the  GROUP  and 
WORLD  categories  have  READ  and  EXECUTE  access. 

To  determine  access  to  a  file,  the  system  uses  the  resource's 
protection  code  for  each  user  category.  The  system  checks  user 
categories  from  the  outermost  category  (WORLD)  to  the  innermost 
(SYSTEM).  The  user  can  access  a  resource  as  soon  as  the  system 
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finds  a  user  category  that  allows  the  user  access .  To  deny 
access  to  a  user  category,  all  categories  to  the  right  of  it  must 
also  be  denied  access.  For  example,  even  though  the  file 
protection  code: 

SYSTEM :RWED,  OWNER :RW,  GROUP :RW,  WORLD :RWED 

denies  DELETE  access  to  the  file's  owner,  the  owner  can  still 
delete  the  file  because  DELETE  access  is  given  under  the  WORLD 
category. 


Privileges 

VAX/ VMS  has  thirty-five  different  privileges  that  can  be 
associated  with  a  process.  The  system  administrator  assigns 
privileges  to  a  user  via  the  AUTHORIZE  utility.  The  thirty-five 
privileges  are  described  in  Appendix  A  (see  page  C-1,  "VAX/VMS 
Privileges" ) . 

Four  privileges  directly  affect  the  access  a  user  actually 
receives  regardless  of  the  access  dictated  by  an  ACL  or  UlC-based 
protection  mechanism.  These  four  privileges  are:  SYSPRV  (allows 
a  user  to  access  an  ob^ject  based  on  the  SYSTEM  UIC  protection 
field),  GRPPRV  (allows  access  to  an  object  based  on  the  SYSTEM 
protection  field  when  the  process'  group  match  the  group  of  the 
object's  owner),  READALL  (allows  reading  of  an  object  despite  any 
access  protection),  and  BYPASS  (allows  a  user  to  bypass  all 
access  protection  on  an  object). 


VAX /VMS  Rules  For  Determining  Access 

VAX/VMS  follows  these  steps  to  determine  if  a  user  is  allowed 
access  to  a  particular  object : 

1.  VAX/ VMS  checks  to  see  if  an  ACL  exists.  The  ACL  is 
searched  from  the  first  ACE  to  the  last  until  the  first  match 
or  the  end.  If  the  user  is  granted  access  in  the  ACL,  then 
access  is  granted  and  further  testing  stops.  If  the  user  is 
not  on  the  ACL,  the  system  then  uses  UlC-based  protection  to 
determine  access.  If  the  user  is  refused  access  in  the  ACL, 
the  system  uses  the  SYSTEM  and  OWNER  fields  according  to  the 
UlC-based  protection  scheme  to  determine  whether  access 
should  be  granted.  Access  will  be  granted  to  the  user  if: 
1)  the  user  has  privilege  to  do  so;  or,  2)  the  user  is  the 
owner  of  the  object.  The  latter  is  to  assure  that  the  owner 
of  an  object  is  never  denied  access  to  the  object. 
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2.  If  the  object  does  not  have  an  associated  ACL,  the  system 
uses  UlC-based  protection  to  determine  access  (see  page  15, 
"UIC-Based  Protection"). 


Default  Protection 

VAX/VMS  has  a  series  of  default  protection  mechanisms.  The 
system  administrator  can  define  a  default  UlC-based  protection 
code  for  every  volume  that  is  mounted.  In  addition,  the  users 
can  set  default  UlC-based  protection  codes  or  ACLs  for  their 
directories.  When  a  default  protection  code  has  been  established 
for  a  directory,  all  files  and  subdirectories  created  under  that 
directory  will  have  the  default  protection  (see  page  14,  "Default 
Protection  ACE"). 

Appendix  C  of  "Guide  to  VAX/ VMS  System  Security"  lists  the 
protections  of  all  directories  and  files  of  VMS,  as  delivered  by 
Digital . 


Categorizing  the  Objects 

VAX/VMS  uses  one  or  more  of  the  DAC  protection  mechanisms 
described  in  the  previous  sections  to  protect  objects  and 
devices.  This  section  describes  the  protection  mechanisms  that 
apply  to  specific  objects. 

Objects  that  can  be  used  as  communication  paths  (i.e. , 
inter-process  communication),  such  as  Common  Event  Flags, 
Resource  Locks,  and  Logical  Names  are  objects  that  need  not  be 
controlled  by  the  Trusted  Computing  Base  (TCB)  at  the  C  Division. 
Logical  names  are  the  individual  data  elements  contained  in  the 
logical  name  tables.  Logical  names  could  be  used  to  establish  a 
communication  path  between  users.  Since  logical  names  are 
contained  in  the  logical  name  tables,  they  are  governed  by  the 
same  access  control  mechanism  outlined  in  the  section  on  logical 
name  tables  (i.e.,  ACLs,  UlC-based  protection,  and  privileges). 

The  physical  loading  of  a  disk  or  tape  to  enable  a  user  to  mount 
the  device,  is  handled  by  procedural  methods.  These  methods  are 
outlined  in  the  "Guide  to  VAX/VMS  System  Security" 

The  following  objects  are  internal  to  the  TCB  and  are 
sufficiently  protected  by  the  TCB: 

-  Mailboxes 

-  Queues 

-  Physical  Memory 
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The  following  objects  are  the  security-relevant  objects  under 
control  of  the  TCB: 

-  Devices 

-  Global  Sections 

-  Files  (ODS-2/Files-ll ) 

-  Directories 

-  Logical  Name  Tables 

-  Volumes 


Disk  and  Tape  Volumes 

VAX/VMS  supports  the  protection  of  data  on  disks  at  the  volume 
and  file  level  and  magnetic  tape  media  at  the  volume  level  only. 
The  volume  must  be  in  Files-11  format.  At  the  volume  level, 
VAX/VMS  provides  UlC-based  protection  for  both  disks  and  magnetic 
tapes.  At  the  file  level.  VAX/ VMS  provides  discretionary  access 
control  through  the  use  of  ACLs  for  individual  disk  files  and 
directory  files  that  reside  on  disk  volumes.  In  general,  the 
protection  that  applies  to  a  magnetic  tape  volume  will  also  apply 
to  all  the  files  on  that  volume,  (i.e.,  UlC-based  protection). 
However,  no  protection  is  provided  for  non-Files-11  volumes. 
These  volumes  must  be  protected  by  procedural  methods  as 
described  in  the  "Guide  to  VAX/VMS  System  Security" . 

An  authorized  user  (one  with  VOLPRO  privilege  or  whose  UIC 
matches  the  volume  UIC)  may  mount  a  Files- 11  (a  system-supported 
file  structure)  disk  or  tape  volume  with  the  /FOREIGN  qualifier. 
Doing  so  gives  the  privileged  user  unlimited  access  to  the 
contents  of  the  volume,  regardless  of  the  ACL  or  UIC  protection 
of  files  on  the  volume.  Other  users  are  prevented  from  accessing 
the  volume  during  this  time. 


Devices 

In  addition  to  protecting  the  data  on  mounted  volumes,  VAX/VMS 
also  provides  device-level  protection.  For  most  non-file 
structured  devices  (e.g.,  terminals,  card  readers,  line  printers, 
laboratory  devices,  etc.),  VAX/ VMS  provides  ACL  and  UlC-based 
protection . 


Global  Sections 

A  Global  sec  tion  is  a  piece  of  code  or  data  that  is  part  of  an 
image  and  can  be  shared  among  users.  VAX /VMS  provides  both 
UlC-based  protection  and  ACLs  for  Global  Sections. 
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ijOgical  Name  Tables 

VAX/VMS  provides  several  logical  name  tables  that  are  made 
available  to  the  user.  Logical  name  tables  may  be  protected  by 
ACLs  and  additional  protection  mechanisms  described  below. 

1 .  LNM $  PROCE S S_T ABLE 

The  process  table  contains  logical  names  that  are 
available  to  the  user's  process.  The  system  inserts 
logical  names  into  this  table  at  the  time  the  user  logs 
in.  Users  are  allowed  to  modify  their  own  process' 
logical  name  table. 

2.  LNM$JOB_xxx 

The  job  table  (xxx  is  the  unique  number  for  the  user's 
job  tree)  contains  logical  names  that  are  available  to 
the  user's  process  and  to  any  of  its  subprocesses. 
VAX/VMS  inserts  certain  logical  names  in  this  table  at 
the  time  the  user  logs  in.  Users  can  modify  their  own 
job  table. 

3 .  LNM$GROUP_xxx 

The  group  table  (xxx  is  the  GROUP  number)  contains 
logical  names  that  are  available  to  the  Group.  Only  a 
user  with  GRPPRV  or  GRPNAM  privilege  can  modify  this 
table . 

4.  LNM$ SYSTEM 

The  system  table  contains  logical  names  that  are 
available  to  all  users  on  the  system.  Only  a  user  with 
SYSNAM  or  SYSPRV  privilege  can  modify  this  table. 


5.  LNM$PROCESS_DIRECTORY 

The  process  directory  is  a  logical  najne  table 
containing  the  logical  names  of  the  logical  name  tables 
that  are  available  to  a  process.  This  can  be  modified 
by  the  user. 
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6.  LNM$SYSTEM_DIRECTORy 

The  system  directory  is  a  logical  name  table  containing 
all  the  logical  names  of  the  logical  name  tetbles  that 
are  available  to  all  users.  Only  a  user  with  SYSNAM  or 
SYSPRV  privilege  can  modify  this  table. 


Queues 

VAX/VMS  has  two  types  of  queue  structures  available:  print  and 
batch  queues .  To  create  or  modify  either  of  the  queues  requires 
OPER  privilege.  There  are  some  utilities  available  in  VAX/ VMS 
that  allow  a  user  to  see  what  jobs  are  waiting  to  be  processed  on 
the  queues ,  however ,  the  user  can  not  modify  any  of  the  queue 
entries;  the  information  contained  in  the  queue  entries  is  under 
the  control  of  VAX/ VMS.  VAX/VMS  provides  UlC-based  protection 
for  queues. 


Mailboxes 

VAX/VMS  mailboxes  are  used  for  interprocess  communication  and 
have  both  ACL  and  UlC-based  protection. 


Physical  Memory 

Memory  is  protected  through  the  use  of  hardware  protection 
mechanisms  (see  page  30,  "Memory")  and  privileges. 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  Discretionary  Access  Control 
requirement . 


Object  Reuse 
Requirement 

When  a  storage  object  is  initially  assigned,  allocated, 
or  reallocated  to  a  subject  from  the  TCB's  pool  of 
unused  storage  objects,  the  TCB  shall  assure  that  the 
object  contains  no  data  for  which  the  subject  is  not 
authorized . 
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Applicable  Features 

VAX/VMS  addresses  object  reuse  with  regard  to  primary  memory, 
disk  files  and  volumes . 


Primary  Memory 

Newly  allocated  pages  of  primary  (virtual)  memory  are  always 
cleared  or  overwritten  before  being  made  accessible  to  a  process. 
This  procedure  is  enforced  by  VAX/VMS  memory  management  and 
ensures  that  a  user  can  not  obtain  residual  information  from  the 
primary  memory  pages  allocated  to  the  user's  process. 


VAX/VMS  allows  a  system  administrator  to  clear  a  disk  device  of 
residual  information  before  it  is  made  available  for  use.  This 
is  accomplished  when  the  volume  is  initialized  with  the  ERASE 
attribute.  This  ensures  that  the  volume  starts  out  in  a  secure 
state.  This  same  facility  also  enables  erase-on-delete  (see  page 
22,  "Erase-on-delete")  for  the  volume  (see  "Guide  to  VAX/VMS 
System  Security"). 


Disk  Files 

Object  reuse  for  disk  files  can  be  handled  in  either  of  two  ways. 
One  method  involves  the  erasure  of  a  disk  file  when  it  is  deleted 
or  purged  (known  as  erase-on-delete).  (A  DELETE  action  removes 
the  specified  version(s)  of  the  named  file  from  the  target 
directory.  A  PURGE  action  removes  all  versions,  except  the 
latest  version,  from  the  target  directory.)  The  other  method 
erases  the  file  before  it  is  allocated  (known  as 
erase-on-allocate  or  highwater  marking).  These  two  mechanisms 
are  implemented  in  VAX/VMS  to  prevent  disk  scavenging. 


Erase-on-delete 

VAX/VMS  enables  disk  files  to  be  overwritten  with  a  security 
erase  pattern  when  deleted  or  purged.  This  feature  is 
implemented  voluntarily  by  the  user  with  the  ERASE  qualifier  on 
the  DELETE  and  PURGE  commands.  The  default  security  erase 
pattern  is  a  pattern  of  zeros  and  is  written  once.  The  system 
administrator  can,  however,  change  the  erasure  pattern  as  well  as 
the  number  of  times  the  pattern  is  written  (see  "Guide  to  VAX/ VMS 
System  Security" ) . 
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The  erase-on-delete  technique  can  also  be  implemented  on  an 
individual  volume  basis  using  the  SET  VOLUME /ERASE_ON_DELETE 
command.  Once  this  command  is  executed,  any  file  deleted  or 
purged  that  resides  on  the  volume  is  overwritten  with  the  erasure 
pattern.  The  enforcement  of  erase-on-delete  can  be  changed  by 
the  user  only  if  the  user  has  the  necessary  privilege  (i.e.,  the 
user  is  owner  of  the  volume,  has  a  system  UIC,  or  has  SYSPRV 
privilege).  Note:  if  a  device  has  erase-on-delete  or  highwater 
marking  specified,  an  unprivileged  user  can  not  override 
enforcement  by  the  system  by  specifying  the  NOERASE  attribute  at 
the  time  of  deletion  or  purging. 


Erase-on-allocate  (Highwater  marking) 

The  other  method  by  which  VAX/VMS  deals  with  disk  file  scavenging 
is  through  "highwater  marking".  Using  the  SET 
VOLUME /HIGHWATER_MARKING  command  ensures  that  all  disk  space  to 
be  allocated  or  extended  to  a  process  is  erased  before  the 
process  can  access  it.  Highwater  marking  in  VAX/VMS  ensures  that 
if  a  user  attempts  to  read  beyond  the  point  in  a  file  in  which 
the  user's  process  has  written,  the  user  will  not  obtain  any 
information  to  which  the  user  is  not  authorized  (i.e. ,  the  space 
is  overwritten  with  the  security  pattern  as  it  is  allocated) . 


No  mechanism  is  provided  to  prevent  a  user  from  reading  beyond 
the  end  of  file  on  a  magnetic  tape.  In  addition,  there  is  no 
enforceable  mechanism  for  erasing  a  tape  or  a  file  on  a  tape. 
However,  TU78  and  MSCP  tapes  support  erasure  upon  initialization. 
The  ability  to  read  residual  information  from  magnetic  tapes  is 
not  prevented  in  VAX/ VMS.  Object  reuse  for  magnetic  tapes  must 
be  handled  by  procedural  methods  or  configured  out  of  the  system. 


Images  and  Global  Sections 

Other  objects  that  store  data  include  images  and  global  sections. 
Images  and  mapped  global  sections  are  stored  in  paged  memory. 
Date  within  these  objects  are  not  subject  to  scavanging  because 
the  data  in  the  related  pages  are  erased  when  the  pages  are 
re-allocated. 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  Object  Reuse  requirement. 
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Identification  and  Authentication 
Requirement 

The  TCB  shall  require  users  to  identify  themselves  to 
it  before  beginning  to  perform  any  other  actions  that 
the  TCB  is  expected  to  mediate.  Furthermore,  the  TCB 
shall  use  a  protected  mechanism  (e.g.,  passwords)  to 
authenticate  the  user's  identity.  The  TCB  shall 
protect  authentication  data  so  that  it  cannot  be 
accessed  by  any  unauthorized  user.  The  TCB  shall  be 
able  to  enforce  individual  accountability  by  providing 
the  capability  to  uniquely  identify  each  individual  ADP 
system  user.  The  TCB  shall  also  provide  the  capability 
of  associating  this  identity  with  all  auditable  actions 
taken  by  that  individual. 


Applicable  Features 

VAX/VMS  requires  that  all  users  be  authenticated  before  any  user 
processing  is  allowed,  with  exceptions  noted  below.  The  user 
must  provide  to  the  LOGINOUT.EXE  process  a  username  and  password. 
The  process  then  verifies  the  username  and  password  against  the 
User  Authorization  File  (UAF)  maintained  by  the  System 
Administrator.  In  verifying  the  password,  VMS  first  enorypts(l) 
the  password  entered  by  the  user.  The  encrypted  password  is  then 
compared  to  the  value  stored  in  the  UAF.  With  the  VAX/VMS 
encryption  algorithm,  a  64-bit  hashed  value  is  always  created, 
regardless  of  the  length  of  the  password  entered. 

The  UAF  is  protected  by  the  UlC-based  protection  mechanism  (see 
page  15,  "UIC-Based  Protection"),  and  can  further  be  protected 
using  an  access  control  list . 

Once  a  user  is  successfully  logged  in,  the  system  associates  the 
user's  UIC  with  the  newly  created  process.  All  auditable  user 
actions  are  identified  in  terms  of  the  UIC  of  the  process  that 
caused  the  action. 


(1)  The  evaluation  teeun  did  not  examine  the  encryption  algorithm 
or  implementation. 
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Exceptions  to  Ilsei  Authentication 

There  are  exceptions  to  the  required  user  authentication.  The 
following  features  should  not  be  used  in  order  to  maintain 
individual  accountability: 

1.  Open  accounts  which  require  no  password.  The  user  is  not 
prompted  for  a  password  and  can  begin  user  processing 
immediately. 

2.  Automatic  logins  which  permit  users  to  login  without 
specifying  a  username.  VAX/ VMS  associates  a  username  with 
the  terminal.  Passwords  may  be  used,  if  enabled. 

For  a  description  of  additional  identification  and  authentication 
features  provided  by  VAX/VMS  see  page  43,  "Evaluators'  Comments". 


Cimfilligicn 

VAX/ VMS  Version  4.3  satisfies  the  C2  Identification  and 

Authentication  requirement. 


Audit 

Requirement 

The  TCB  shall  be  able  to  create,  maintain,  and  protect 
from  modification  or  unauthorized  access  or  destruction 
an  audit  trail  of  accesses  to  the  objects  it  protects. 
The  audit  data  shall  be  protected  by  the  TCB  so  that 
read  access  to  it  is  limited  to  those  who  are 
authorized  for  audit  data.  The  TCB  shall  be  able  to 
record  the  following  types  of  events:  use  of 

identification  and  authentication  mechanisms, 
introduction  of  objects  into  a  user's  address  space 
(e.g.,  file  open,  program  initiation),  deletion  of 
objects,  and  actions  taken  by  computer  operators  and 
system  administrators  and/or  system  security  officers. 
The  TCB  shall  also  be  able  to  audit  any  override  of 
human-readable  output  markings.  For  each  recorded 
event,  the  audit  record  shall  identify:  date  and  time 
of  the  event,  user,  type  of  event,  and  success  or 
failure  of  the  event.  For 

identification/authentication  events  the  origin  of 
request  (e.g.,  terminal  ID)  shall  be  included  in  the 
audit  record.  For  events  that  introduce  an  object  into 
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a  user's  address  space  and  for  object  deletion  events 
the  audit  record  shall  include  the  name  of  the  object. 
The  ADP  system  administrator  shall  be  able  to 
selectively  audit  the  actions  of  any  one  or  more  users 
based  on  individual  identity. 


Applicable  Features 

VAX/VMS  audits  security-relevant  events  through  a  variety  of  logs 
including  an  operator  log,  an  accounting  log,  and  operator  and 
system  administrator  session  logs.  Additionally,  it  is  possible 
and  may  be  desirable  to  enable  the  system  console,  or  some  other 
terminal,  as  a  security  console.  This  results  in  all 
security-relevant  events  normally  logged  in  the  operator  log  to 
also  be  displayed  at  this  console.  For  auditing  to  occur,  a 
privileged  user  must  enable  the  auditing  mechanism. 

The  auditable  events  include  successful  logins,  unsuccessful 
login  attempts,  logouts,  successful  object  accesses,  object 
access  failures,  process  initiations,  process  initiation 
failures,  direct  audit  of  certain  privileges,  privileged  user 
actions,  volume  mounts  and  accesses  to  selected  system  files. 

The  ACCOUNTING  utility  is  used  to  gather  and  report  successful 
login  information  and  login  failures.  ACCOUNTING  can  be  used  to 
selectively  extract  information  from  the  accounting  log  file, 
SYS$MANAGER: ACCOUNTNG.DAT.  The  login  failures  are  supplemented 
with  extensive  information  as  to  the  reason  for  failure,  such  as 
incorrect  password,  expired  password,  expired  account,  improper 
job  class,  improper  day  or  time  for  login,  or  breah-in 
prevention.  The  accounting  log  file  also  contains  logout 
information  and  exit  conditions.  In  addition,  a  security  alarm 
feature  can  be  used  to  record  logins,  login  failures  and  breakin 
attempts.  These  events  are  recorded  in  the  system's  operator 
log,  SYS$ MANAGER: OPERATOR. LOG.  The  operator  log  and  the 
accounting  log  are,  by  default,  accessible  only  by  privileged 
users  such  as  Security  Administrators . 

VAX/ VMS  performs  complete  auditing  of  mounting  of  user  and  system 
volumes.  Recorded  information  includes  the  device  type,  ledoel, 
logical  name,  owner,  protection,  requestor's  name,  and  current 
date  and  time.  The  SET  AUDIT  command  will  cause  the  audit  data 
to  be  placed  in  the  operator  log  file  and  simultaneously 
displayed  on  the  system  console . 

VAX/VMS  provides  the  capability  to  audit  selectable  types  of 
access  on  files  and  global  sections.  The  files  must  be  located 
on  Files- ll/ODS-2  structured  disks.  The  selectable  access  types 
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are  READ,  WRITE.  EXECUTE,  DELETE,  and  CONTROL.  These  access 
types  can  be  further  defined  by  combining  them  with  either 
successful  accesses,  failures,  or  both.  For  example,  a  security 
administrator  may  specify  that  only  write  failures  be  audited,  or 
only  read  successes  be  audited. 

Special  user  functions  are  finely  controlled  via  a  set  of 
thirty-five  privileges  (see  page  C-1,  "VAX/VMS  Privileges"). 
However,  VAX/ VMS  is  only  capable  of  directly  auditing  the  use  of 
four  of  these  privileges.  They  are  BYPASS,  GRPPRV,  READALL,  and 
SYSPRV.  File  or  global  section  accesses  using  these  privileges 
can  be  audited.  There  are  nine  other  security-relevant 
privileges  which  are  not  automatically  audited.  These  nine 
privileges  are  CMEXEC  and  CMKRNL  (both  allow  executing  privileged 
instructions  and  full  access),  LOG_IO  and  PHY_IO  (allows 
low-level  I/O),  PFNMAP  (allows  a  user  to  map  to  specific  physical 
pages  in  memory),  SECURITY  (allows  a  user  to  perform 
security-related  functions),  SETPRV  (to  turn  on  any  privilege), 
SYSNAM  (to  modify  system  logical  name  table),  and  VOLPRO  (which 
in  conjunction  with  SYSNAM  allows  users  to  indirectly  access  any 
file  on  any  volume). 

However,  use  of  all  privileges  can  be  indirectly  audited.  This 
indirect  method  involves  creating  executable  files  which  perform 
desired  privileged  functions.  Such  files  are  first  protected 
with  proper  ACLs  and  then  installed  in  the  operating  system. 
Auditing  accesses  to  these  files  will  then  produce  a  record  of 
use  of  the  privileges  (see  “Guide  to  VAX/VMS  System  Security"). 

VAX/VMS  is  capable  of  auditing  successful  and  unsuccessful 
process  creations,  image  activations  and  accesses  to  logical  name 
tables . 

All  modification  attempts  on  the  user  authorization  file, 
SYS$ SYSTEM : SYSUAF . DAT,  are  also  auditable,  however,  the  audit 
entries  include  only  the  account  name,  the  new  parameter  name  and 
the  user  who  performed  the  modification.  (The  actual  value  of 
the  old  parameter  can  only  be  audited  via  a  session  log.) 

System  Administrator  and  Operator  actions  can  be  recorded  from  a 
session  log  in  a  captive  account.  This  will  record  all  actions 
taken  by  the  user. 

In  addition,  VAX/ VMS  records  the  date  and  time  of  event,  the 
user,  and  the  event  type.  Success  or  failure  of  an  action  can 
also  be  audited.  For  identification  and  authentication  events, 
the  origin  of  the  request  is  recorded  and  for  object  access 
events,  the  name  of  the  object  is  specified. 
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VAX/ VMS  applies  auditing  criteria  to  a  specified  object  or  user. 
In  addition,  an  audit  reduction  tool  is  provided  with  the  system 
to  allow  further  selectivity  in  extracting  data  from  the  audit 
logs.  The  Security  Administrator  may  specify  user  names, 
particular  time  frames,  or  particular  types  of  events  as  the 
audit  reduction  criteria. 

Warnings  concerning  the  possibility  of  audit  log  overflow  will  be 
generated  by  the  system  (see  "The  VAX/VMS  Systems  Dispatch", 
article  95.5.8).  This  will  allow  a  System  Administrator  to  take 
corrective  action  before  audit  records  are  lost  due  to  a  full 
system  disk. 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  Audit  requirement. 


System  Architecture 
Requirement 

The  TCB  shall  maintain  a  domain  for  its  own  execution 
that  protects  it  from  external  interference  or 
tampering  (e.g.,  by  modification  of  its  code  or  data 
structures).  Resources  controlled  by  the  TCB  may  be  a 
defined  subset  of  the  subjects  and  objects  in  the  ADP 
system.  The  TCB  shall  isolate  the  resources  to  be 
protected  so  that  they  are  subject  to  the  access 
control  and  auditing  requirements. 


Applicable  Features 

"Digital  Equipment  Corporation  Standard  032"  defines  the  VAX 
architecture  (see  page  E-1,  "References").  The  security-relevant 
portions  of  the  VAX  architecture  and  of  the  VMS  operating  system 
are  common  on  a  wide  range  of  hardware  implementations.  Norden 
Systems , Inc . ,  which  manufactures  militarized  implementations  of 
the  VAX  architecture  under  license  from  Digital  Equipment 
Corporation,  also  meet  the  standard  and  run  VMS  unchanged. 

VAX/VMS  provides  several  security-relevant  protection  mechanisms 
in  hardware  and  software  to  provide  process  seperation  and 
resource  isolation. 
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Processor  Modes 

The  VAX  has  four  hierarchical  processor  protection  modes  (see 
page  10,  "Mode  Switching  Instructions").  From  most  to  least 
privileged  they  are:  Kernel,  Executive,  Supervisor,  and  User. 
Each  mode  maintains  its  own  stack.  Movement  from  less  privileged 
to  the  same  or  more  privileged  modes  is  performed  by  the 
execution  of  instructions  or  exceptions  (software  interrupts). 
These  exceptions  include  the  translation  not  valid  (virtual 
address  not  mapped  into  physical  memory)  fault  for  memory 
management  as  well  as  the  Change_Mode_To_Kernel , 
Change_Mode_To_Executive ,  Change_Mode_To_Supervisor ,  and 
Change_Mode_To_User  instructions.  These  instructions  are  used  by 
the  system  services  which  may  execute  in  the  same  or  a  more 
privileged  access  mode  (see  page  10,  "Mode  Switching 
Instructions" ) . 

When  a  change  mode  instruction  is  executed,  the  processor 
switches  to  the  stack  of  the  specified  mode.  The  Processor 
Status  Longword  (PSL)  and  Program  Counter  (PC)  are  saved  on  the 
new  stack.  The  new  PSL  is  formed  with  the  caller's  mode  in  the 
previous  mode  field  and  the  current  mode  in  the  current  mode 
field.  The  processor  then  runs  in  the  higher  mode.  Because  the 
change  mode  is  really  an  interrupt,  the  address  of  the  transfer 
is  fixed  by  the  system.  Thus,  it  is  possible  for  the  system  to 
do  parameter  checking  and  have  a  dispatch  table  for  the  final 
servicing.  It  is  not  possible  for  a  user  to  jump  to  arbitary 
locations  at  arbitrary  processor  modes.  The  instructions  provide 
the  only  mechanism  for  less  privileged  code  to  call  more 
privileged  code. 

When  a  mode  transition  occurs,  the  previous  mode  is  save  in  the 
previous  mode  field  of  the  PSL.  This  allows  the  more  privileged 
code  to  determine  the  privilege  of  its  most  recent  caller. 

The  Return_from_Exception_Or_Interrupt  (REI)  instruction  provides 
a  common  return  path  and  implements  the  protection  scheme  for  the 
movement  from  more  privileged  to  less  privileged  modes.  When 
this  instruction  is  executed,  the  top  of  the  current  stack 
contains  the  PSL  and  PC  of  the  new  mode.  The  processor  verifies 
that  the  new  mode  is  at  the  same  or  less  privilege  than  the 
current  mode.  Thus,  the  instruction  can  not  be  used  to  increase 
the  privilege  of  the  processor  access  mode. 
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Privileged  Instructions 

There  are  some  instructions  which  may  only  be  executed  from 
Kernel  mode.  These  are:  HALT,  Save_Process_Context  (SVPCTZ), 
Load_Process_Context  (LDPCTX),  Move_To_Processor_Register  (MTPR), 
and  Move_From_Processor_Register  (MFPR).  The  SVPCTZ  and  LDPCTX 
instructions  assist  VMS  in  the  switching  of  process  context  by 
saving  and  restoring  the  general  registers  and  memory  management 
registers  from  the  process  control  block  (see  page  6,  "User 
Process").  The  MTPR  and  MFPR  provide  access  to  processor 
internal  privileged  registers.  Examples  of  these  registers 
include:  inner  mode  stack  registers,  base  and  bounds  registers, 
interval  counters,  interrupt  processors,  and  system 
identification . 


Memory 

The  paged  memory  hierarchy  is  implemented  so  that  a  read  or  write 
to  memory  which  is  permissible  in  a  less  privileged  mode  will 
also  be  allowable  in  a  more  privileged  mode.  Memory  protection 
is  on  a  per-page  (512  byte)  basis.  Privileged  data  structures 
can  be  protected  by  not  allowing  read  nor  write  access  to 
nonprivileged  users. 

The  Probe_Read  and  Probe_Write  instructions  assist  privileged 
mode  routines  in  verifying  that  less  privileged  code  actually  has 
access  to  arguments  which  they  are  passing.  It  does  this  by 
checking  the  access  protection  of  the  memory  page  containing  the 
argument  as  seen  by  the  most  recent  caller . 

Each  process  has  its  own  virtual  address  space.  Translation  from 
virtual  addresses  to  physical  addresses  is  under  strict  control 
of  VAX/ VMS.  The  combination  of  processor  modes,  privileged 
instructions,  and  memory  access  protection  provide  VAX/VMS  with 
its  own  domain  and  allows  for  process  isolation  by  the  use  of 
distinct  address  spaces  for  user  processes  (see  page  6,  "User 
Process" ) . 
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Software  Security  Features 


TCB  Layering 

VMS  is  layered  with  the  kernel  executing  in  Kernel  mode,  the 
Record  Management  Services  (RMS,  a  file  system)  in  Executive 
mode,  the  Command  Language  Interpreter  (CLI)  in  Supervisor  mode, 
and  user  written  images  in  User  mode.  Some  system  utilities 
installed  with  privileges  execute  in  User  mode.  These  images  are 
protected  by  the  use  of  special  options  in  compilation  and 
linking  (to  prevent  the  use  of  the  interactive  debugger)  as  well 
as  control  of  the  process  address  space. 


Processes 

The  process  is  the  fundamental  subject  of  VMS.  It  is  the  entity 
selected  for  execution  by  the  scheduler.  A  job  is  the  collection 
of  a  process  and  all  of  its  subprocesses.  An  image  is  the 
program  a  process  executes  in  order  to  do  meaningful  work.  A 
process  is  fully  described  by  the  hardware  and  software  contexts 
and  a  virtual  address  space  description. 

The  hardware  context  consists  of  the  contexts  of  the  general 
purpose  registers,  the  four  per-process  stack  pointers,  the 
program  counter,  the  processor  status  longword,  the  process 
specific  processor  registers  including  the  memory  management  and 
asynchronous  system  trap  (AST,  an  interrupt  scheme)  level 
registers.  The  software  context  includes  information  about 
priority,  scheduling  state,  process  privileges,  resource  quotas, 
and  the  unique  process  identification  (PID). 

Each  process  has  its  own  user  virtual  address  space  (PO  process 
specific  code  and  PI  process  specific  information)  as  well  as 
shared  system  address  space  (SO).  The  process  virtual  address 
space  is  altered  when  an  image  is  initially  activated,  during 
image  execution  through  selected  system  services,  and  when  an 
image  terminates.  The  PO  and  PI  address  space  of  a  process  is 
not  accessible  to  the  code  running  in  the  context  of  another 
process . 
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TCB  Interface 

The  fundamental  user  interface  with  the  TCB  is  the  system 
services  (see  "VAX/VMS  System  Services  Reference  Manual").  The 
system  services  provide  a  uniform  mechanism  for  the  execution  of 
system  routines.  These  services  are  implemented  by  using  the 
hardware  protection  schemes  (mainly  the  change  mode  exception 
dispatch  scheme  discussed  on  page  29,  “Processor  Modes"). 

There  are  110  system  services  which  may  be  grouped  into: 
security,  event  flags,  AST,  logical  name,  input /output ,  process 
control,  timer  and  time  conversion,  condition  handling,  memory 
management ,  and  lock  management .  One  important  group  of  system 
services  is  for  security.  This  group  includes  services  to 
implement  the  rights  database,  identifiers,  access  control  list 
entries,  access  protection  checking  and  security  erase.  These 
system  services  provide  the  primitive  operations  for  many  of  the 
system  utilities. 

For  example,  users  are  defined  by  the  system  administrator  by  use 
of  the  AUTHORIZE  utility.  This  utility  makes  use  of  the 
following  system  services:  $CREATE_RDB  (create  a  rights 
database),  $ADD_HOLDER  (add  holder  record  to  rights  database), 
$ADD_IDENT  (add  identifier  to  rights  database),  $FIND_HELD 
(returns  identifiers  held  by  a  holder),  $FIND_HOLDER  (returns 
holders  of  an  indentifier  in  rights  database),  $MOD_HOLDER 
(modifies  holder  record  in  rights  database,  $MOD_IDENT  (modifies 
identifier  record  in  rights  database),  $REM_HOLDER  (deletes 
holder  record  from  identifiers  list  of  holders  in  rights 
database),  $REM_IDENT  (deletes  identifier  and  all  holders  of  that 
identifier  in  rights  database),  and  SREVOKID  (removes  identifier 
from  process  or  system  rights  list). 

VMS  isolates  objects  by  allowing  access  only  through  system 
service  calls,  RMS  calls,  or  CLI  commands  which  all  execute  in 
more  privileged  processor  modes  than  the  user  and  which  implement 
the  security  policy.  The  TCB  provides  isolation  of  its  resources 
by  controlling  their  manipulation  through  the  system  service 
interface . 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  System  Architecture 
requirement . 
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System 


Requirement 


Hardware  and/or  software  features  shall  be  provided 
that  can  be  used  to  periodically  validate  the  correct 
operation  of  the  on-site  hardware  and  firmware  elements 
of  the  TCB. 


Applicable 


VMS  has  a  number  of  methods  for  verifying  continued  correct 
operation  of  the  TCB. 


Installation  Testing 

A  utility  called  the  User  Environment  Test  Package  (UETP)  can  be 
used  to  check  system  performance,  both  hardware  and  software.  It 
is  basically  an  exerciser  that  runs  test  loads  that  simulate 
users  running  programs  which  access  disk  files  while  checking 
file  system  inconsistencies.  This  permits  checking  bad  quota, 
privilege,  or  account  fields  in  the  user  authorization  file 
( SYS $ SYSTEM: SYSUAF.DAT) . 

UETP  also  performs  some  minor  diagnostics  such  as  tape  drive 
vacuum  failure  and  device  failure  (either  hardware  or  software) 
for  devices  that  are  connected  to  queues.  UETP  should  only  be 
regarded  as  a  first  phase  of  a  comprehensive  diagnostic 
procedure.  The  program  does  not  try  to  diagnose  the  cause  of  the 
error  but  reports  the  error,  quits  that  pass  of  the  program,  and 
continues  with  the  next  test.  The  error  logger  and  Digital 
supplied  diagnostics  should  be  used  to  diagnose  unknown  problems. 


Eimr  bogging 

The  ERRFMT  process  keeps  track  of  system  errors,  storing  them  in 
the  file  SYS$ERRORLOG:ERRLOG. SYS.  This  file  contains  such 
hardware  related  errors  as  MASSBUS  device  errors,  UNIBUS  device 
errors.  Error  Correction  Code  (ECO  errors.  Interrupt  Exception 
Conditions  (lEC),  and  machine  checks,  in  addition  to  system 
software  related  errors  such  as  bugchecks.  Error  correction 
codes  repair  single-bit  errors  and  detect  double-bit  errors. 
This  file  also  has  an  associated  report  generator,  the  Error  Log 
utility,  which  is  used  to  analyze  this  file. 
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Another  process  with  a  similar  function  is  the  OPCOM  process. 
The  OPCOM  process  captures  all  operator  output  that  is  printed  on 
the  console  as  well  as  system  events.  This  facility  sends 
information  that  is  used  by  operations  personnel  to  the  file 
SYS $ MANAGER : OPERATOR . LOG ,  such  as  security  alarm  messages,  system 
volume  mounts  and  dismounts  (tape  and  disk),  changes  to  the 
operating  system  parameters  through  SYSGEN,  and  user  requests  to 
mount  and  dismount  volumes.  There  exists  a  utility  (REPLY)  which 
has  as  an  option  to  close  out  the  old  OPERATOR.LOG  file  and  open 
a  new  one.  Both  the  currently  used  file  and  all  previously  used 
files  are  stored  as  ASCII  text  and  thus  can  easily  be  reviewed. 


Hardware  Diagnostics 

All  VAX/VMS  systems  are  supplied  with  a  set  of  the  standard  VAX 
system  hardware  diagnostics.  These  diagnostics  check  the  proper 
operation  of  the  hardware,  including  testing  the  correct  function 
of  the  microcode,  and  the  data  path  circuitry  used  in  the  address 
translation  logic  of  the  virtual  memory  system. 


VAX/ VMS  Version  4.3  satisfies  the  C2  System  Integrity 
requirement . 


Seovrity  Testing 
Requirement 

The  security  mechanisms  of  the  ADP  system  shall  be 
tested  and  found  to  work  as  claimed  in  the  system 
documentation.  Testing  shall  be  done  to  assure  that 
there  are  no  obvious  ways  for  an  unauthorized  user  to 
bypass  or  otherwise  defeat  the  security  protection 
mechanisms  of  the  TCB.  Testing  shall  also  include  a 
search  for  obvious  flaws  that  would  allow  violation  of 
resource  isolation,  or  that  would  permit  unauthorized 
access  to  the  audit  or  authentication  data. 


Applicable  Features 

The  evaluation  team  performed  functional  testing  of  the  security 
features  of  VAX/ VMS  Version  4.3  on  a  VAX  11/750,  microcode 
revision  level  98,  in  May  1986  at  a  Digital  site.  The  security 
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features  were  tested,  as  per  Section  10,  "A  Guideline  on  Security 
Testing"  of  the  Criteria,  and  found  to  work  as  claimed  in  the 
system  documentation.  No  obvious  ways  to  bypass  the  security 
features  of  the  system  were  discovered  and  no  obvious  flaws  were 
found  during  testing  or  documentation  review. 

In  addition  to  re-running  the  complete  set  of  Digital's  test 
suite  (see  page  38,  "Test  Documentation"),  the  team  executed  a 
set  of  12  tests  they  designed.  These  tests  were  in  the  following 
general  areas: 

Auditing:  verified  that  all  auditable  actions  were  recorded  and 
the  audit  reduction  tool  worked  as  documented. 

Discretionary  Access  Control:  verified  that  the  appropriate 

privilege  was  required  before  a  privileged  operation  could  take 
place , 

Identification  and  Authentication:  verified  that  various  login 
restriction  combinations  and  password  restrictions  were  enforced, 

Object  Reuse:  verified  main  memory  was  cleared  and  disk  files 

spread  over  more  than  one  volume  were  cleared, 

Trusted  Path:  verified  the  functionality  of  the  secure  terminal 
server  mechanism. 


Test  Configuration 

The  following  is  a  description  of  the  configuration  that  the 
evaluation  team  used  to  test  VMS: 

VAX  11/750  CPU  with  6MB  memory 


2 

-  RA60 

205MB  Disks 

1 

-  RL02 

10.4MB  Disk 

1 

-  TU77 

Tape  Drive 

2 

-  DZll 

8  Port  Async  MUX 

1 

-  DEUNA 

Ethernet  Controller 

1 

-  LA120 

DecWriter  III  Console  Terminal 

1 

-  VTIOO 

Terminal 

2 

-  DF03 

1200  Baud  Modems 
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VAX  11/730  CPU  with  3MB  Memory 


1 

-  R80 

121  MB  Disk 

2 

-  RL02 

10.4  MB  Disk 

1 

-  TSll 

Tape  Drive 

3 

-  DZll 

8  Port  Async  MUX 

1 

-  LA120 

DecWriter  III  Console  Terminal 

1 

-  DEUNA 

Ethernet  Controller 

4 

1 


DELNI  Local  Network  Interconnect 

VTIOO  Terminals 

LAIOO  Hardcopy  Termial 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  Security  Testing 
requirement . 


Security  Features  User's  Guide 
Requirement 

A  sihgle  summary,  chapter,  or  manual  in  user 
documentation  shall  describe  the  protection  mechanisms 
provided  by  the  TCB,  guidelines  on  their  use,  and  how 
they  interact  with  one  another. 


Applicable  Features 

Chapters  1-4  of  the  "Guide  to  VAX/VMS  System  Security"  are 
written  for  the  general  user.  These  four  chapters  describe  the 
protection  mechanisms,  guidelines  on  their  use,  and  how  they 
interact  with  one  another. 

Chapter  1  introduces  the  topic  of  security  and  levels  of  security 
requirements. 

« 

Chapter  2  introduces  the  reference  monitor  concept  for  security 

design  and  includes  an  overview  of  the  security  features  provided  i 

by  VMS. 

Chapter  3  contains  information  on  system  security  of  interest  to 
all  users.  This  includes  types  of  logins,  information  supplied 
at  login  time  (e.g.,  last  login  message),  the  password  facility, 
common  causes  of  login  failures  and  loging  off. 
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Chapter  4  describes  the  VMS  object  protection  features  that  a 
user  needs  to  know  to  protect  the  user's  own  information.  This 
includes:  UlC-based  protection,  access  control  lists, 
eatablishing  and  changing  ownership  of  objects,  default 
protection,  preventing  disk  scanenging,  user  auditing,  as  well  as 
a  user  self -test  on  protection  techniques  available. 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  Security  Features  User's 
Guide  requirement . 


Trusted  Facility  Manual 
Requirement 

A  manual  addressed  to  the  ADP  system  administrator 
shall  present  cautions  about  functions  and  privileges 
that  should  be  controlled  when  running  a  secure 
facility.  The  procedures  for  examining  and  maintaining 
the  audit  files  as  well  as  the  detailed  audit  record 
structure  for  each  type  of  audit  event  shall  be  given. 


Applicable  Features 

Chapters  1-4  of  the  "Guide  to  VAX/VMS  System  Security"  are 
written  for  the  general  user,  and  the  other  chapters  in  the  guide 
are  written  for  the  system  manager. 

Chapter  5  describes  VMS  security  features  of  particular  interest 
to  security  managers.  Specifically,  section  5.8  describes  the 
procedures  for  examining  and  maintaining  the  audit  files. 
Additional  audit  information  may  be  found  in  the  "VAX/ VMS  DCL 
Dictionary",  the  "Guide  to  Networking  on  VAX/VMS",  the  "Guide  to 
VAX/ VMS  System  Management  and  Daily  Operations"  and  in  the 
"VAX/VMS  Accounting  Utility  Reference  Manual" . 

Chapter  6  provides  guidance  on  recognizing  when  a  system  is  under 
attack  and  summarizes  the  actions  available  to  security  managers 
to  protect  their  systems.  In  addition,  instructions  on  how  to 
handle  recent  VMS  security  problems  may  be  found  in  the  "The 
VAX/VMS  Systems  Dispatch,"  published  bimonthly.  Chapter  7 
describes  security  considerations  for  systems  in  networks. 
Chapter  8  describes  security-related  actions  specific  to 
clustered  systems. 
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Appendix  A  summarizes  all  privileges  available  in  VMS,  the 
functionality  they  provide  and  which  users  should  receive  them. 
Appendix  B  describes  how  to  modify  user  data  in  the  User 
Authorization  File.  Appendix  C  lists  the  UlC-based  protection 
that  VMS  provides,  by  default  when  delivered,  for  system  files. 
Appendix  D  describes  how  to  operate  VMS  in  a  C2  environment . 
Appendix  E  provides  the  detailed  audit  structure  resulting  from 
particular  alarm  events. 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  Trusted  Facility  Manual 
requirement . 


Test  Documentation 
Requirement 

The  system  developer  shall  provide  to  the  evaluators  a 
document  that  describes  the  test  plan  and  results  of 
the  security  mechanisms'  functional  testing. 


Applicable  Features 

This  requirement  is  satisfied  by  a  test  suite  and  the 
accompanying  documentation  that  the  evaluation  team  reviewed 
on-line  in  the  'test'  directory  of  a  Digital  provided  system.  A 
majority  of  the  the  test  suite  were  designed  to  execute  in  an 
automated  manner. 

Digital's  test  documentation  suite  uncovered  two  security  flaws 
in  an  earlier  version  of  VMS.  These  flaws  were  corrected  in  the 
evaluated  version. 

Digital  also  provided  two  documents  that  presented  an  overview  to 
the  test  documentation  suite: 

-  "VAX/VMS  Security  Evaluation  Functional  Test  Plan" 

-  "VAX/ VMS  Security  Evaluation  Functional  Testing  Report  For 
VAX/VMS  Version  4.3". 

The  following  is  a  brief  description  of  the  scope  of  tests 
described  in  the  aforementioned  reports. 
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Identification  and  Authentication 

The  Login  Control  tests  demonstrate  the  success  and  failure  of 
user  access  attempts  to  the  system.  They  verify  that  only  those 
attempts  where  the  user  is  properly  identified  to  the  system  by 
means  of  an  unique  username  and  valid  password  will  succeed. 

The  Process  Rights  Identifier  tests  demonstrate  the  use  of  the 
AUTHORIZE  utility.  This  utility  maintains  the  system 
authorization  database  used  to  create  and  modify  user  accounts  on 
the  system  and  to  maintain  a  set  of  rights  identifiers  which  are 
acquired  by  users  when  they  gain  access  to  the  system. 


Discretionary 


For  each  class  of  objects  protected  by  VMS  the  tests  used  a  set 
of  standard  users  possessing  various  combinations  of  UICs,  system 
identifiers,  general  identifiers  and  privileges.  Each  of  these 
users  then  attempted  at  least  one  Read,  Write,  Execute,  Delete, 
and  Control  action  against  every  object  defined  for  testing  that 
class . 


Object  Reuse 

Three  tests  were  developed  that  test  the  three  different  methods 
VMS  uses  to  implement  object  reuse.  The  three  methods  are:  i) 
erase  on  delete  (at  the  user's  option),  2)  erase  on  delete  (site 
enforced),  and  3)  erease  on  allocate  (highwater  marking). 


Audit 

The  audit  tests  showed  that  when  an  auditable  event  occurred,  the 
proper  audit  record  was  written.  Once  all  auditable  events  are 
created,  the  test  uses  the  audit  data  reduction  facility, 
SECAUDIT,  to  extract  the  audit  information. 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  Test  Documentation 
requirement . 
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Design  Documentation 
Requirement 

Documentation  shall  be  available  that  provides  a 
description  of  the  manufacturer's  philosophy  of 
protection  and  an  explanation  of  how  this  philosophy  is 
translated  into  the  TCB.  If  the  TCB  is  composed  of 
distinct  modules,  the  interfaces  between  these  modules 
shall  be  described. 


Applicable  Features 

Chapter  2  of  the  "Guide  to  VAX/VMS  System  Security '  documents  the 
overall  philosophy  of  protection  underlying  the  design  of  VMS, 
and  its  translation  into  the  specific  features  that  are 
incorporated  in  the  system. 

The  TCB  is  isolated  into  individual  functional  modules,  whose 
interfaces  are  specified.  This  is  documented  in  "VAX /VMS 
Internals  and  Data  Structures". 


Conclusion 

VAX/ VMS  Version  4.3  satisfies  the  C2  Design  Documentation 
requirement . 
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ADDITIONAL  SECURITY  FEATURES 


Introduction 

This  section  presents  an  evaluation  of  a  VAX/VMS  security  feature 
that  exceeds  the  C2  requirements.  The  feature  described  in  this 
section  does  satisfy  the  higher  level  requirements  of  the 
Criteria  in  terms  of  the  capability  provided,  but  does  not  meet 
any  of  the  assurance  requirements  above  the  C2  class. 


Trusted  Path 
Requirement 

The  TCB  shall  support  a  trusted  communication  path 
between  itself  and  users  for  initial  login  and 
authentication.  Communications  via  this  path  shall  be 
initiated  exclusively  by  a  user. 


Applicable  Features 

There  is  a  secure  terminal  server  feature  which  invokes  the  login 
process  on  behalf  of  the  user.  This  server  can  be  invoked  by  the 
user  pressing  the  Break  key  followed  by  a  Return  key  on  a 
terminal . 

It  can  be  implemented  on  a  terminal  by  terminal  basis.  This 
facility  will  stop  any  currently  executing  process  prior  to  the 
start  of  a  login  at  that  terminal.  An  application  that  uses  the 
Break  key  for  its  own  purpose  will  be  affected  by  this  option. 
The  "Guide  to  VAX/VMS  System  Security"  describes  how  to  implement 
the  feature  on  either  direct  connect  or  switched  (e.g.,  modem) 
terminals . 


Conclusion 

VAX/VMS  Version  4.3  satisfies(l)  the  B2  Trusted  Path  requirement. 


(1)  Although  VAX/ VMS  Version  4.3  satisfies  this  requirement  at 
the  B2  level,  it  does  not  satisfy  the  assurance  requirements 
above  its  rated  level. 
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EVALUATORS'  COMMENTS 


This  section  consists  of  comments  and/or  opinions  from  the 
evaluation  team  in  the  following  areas ; 

-  security  features  provided  by  the  system  (or  vendor)  that 
are  not  required  by  the  Criteria, 

features  provided  by  the  system  (or  vendor)  that  are 
required  by  the  Criteria  but  at  a  level  higher  than  this 
evaluation  was  focused, 

-  the  useability  of  some  of  the  features  that  satisfy  the 
Criteria  requirements. 


Discretionary  Ac-cess  Control 

VAX/VMS  contains  many  types  of  storage  objects  for  many  different 
purposes.  Although  there  are  protection  mechanisms  to  permit 
sharing  the  different  objects  between  users,  the  protection 
mechanisms  are  not  consistent  across  all  objects  (e.g.,  there  are 
ACLs  and  UlC-based  protection  for  disk  files,  but  only  UIC 
protection  for  volumes). 


Identification  and  Authentication 

VMS  also  provides  the  capability  to  take  'evasive  action'  when  a 
penetrator  (possibly  via  an  automatic  password  generator)  has 
targeted  a  user's  account.  If  a  site-defined  threshold  of  failed 
login  attempts  is  exceeded,  the  account  will  be  identified  as  one 
where  a  breakin  is  suspected.  Real-time  alarms  may  also  be 
triggered.  Once  an  account  is  under  suspicion  no  logins  can 
occur  on  that  account,  even  if  a  valid  password  is  entered.  The 
threshold  (site  setable)  is  based  upon  the  number  of  failed 
attempts  per  unit  time.  Only  when  the  rate  of  attempted  logins 
goes  below  the  threshold  can  a  valid  login  attempt  occur  on  that 
account.  This  protection  is  also  available  on  an  account /port 
basis.  This  helps  thwart  a  Denial  of  Service  attack  on  system 
accounts/ports  while  still  protecting  the  system. 

VAX/VMS  provides  many  useful  tools  for  the  Security  Administrator 
to  use  for  password  management.  This  includes;  the  ability  for 
VMS  to  force  users  to  use  system  generated  (pronounceable) 
passwords,  password  expiration.  and  minimum  password  length. 
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Also,  there  is  the  capability  for  a  site  to  specify  a  system-wide 
password  to  control  access  to  particular  terminals.  The  correct 
system  password  must  be  entered  before  the  user  receives  the 
username  prompt  to  begin  logging  in.  For  sensitive  accounts,  two 
separate  passwords  can  be  required  before  login  is  completed. 


Audit 


The  system  should  have  the  capability  to  audit  the  use  of 
privileges  directly,  via  the  audit  mechanism,  not  just  the 
assignment  of  them.  Because  of  the  ease  of  privilege 
proliferation,  the  proper  management  of  privileges  could  go  a 
long  way  towards  increasing  a  site's  security. 

The  system  should  have  a  capability  to  audit  more  system 
administrator  actions  directly  (via  the  audit  mechanism,  instead 
of  depending  upon  session  logs)  as  well  as  modifications  to 
access  control  lists  by  users. 

The  audit  mechanism  can  suffer  from  useability  problems. 

The  system  should  have  the  capability  to  audit  the  allocation  of 
all  devices ., 

It  is  worthy  to  note  that  the  login  information  is  not  recorded 
in  the  accounting  log  ( SYS $ MANAGER . ACCOUNTNG . DAT)  until  a  user 
logs  out.  However,  user  login  and  logout  information  can  be 
obtained  from  the  operator  log  ( SYS $ MANAGER : OPERATOR . LCXJ) . 

Users  have  the  capability  to  specify  auditable  events  on  files 
they  own.  These  events  are  independent  of  what  the  System 
Administrator  selects  to  be  audited  (however,  the  audit  mechanism 
must  be  enabled  by  the  System  Administrator  for  any  logging  to 
occur) . 

VAX/VMS  has  the  capability  to  generate  real-time  alarms  on  (user 
and/or  System  Administrator)  selected  events. 


Testing 


It  is  the  team's  view  that  the  tests  used  to  satisfy  the  Test 
Documentation  requirement  be  incorporated  into  Digital's 
corporate  quality  assurance  program. 
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Dooumentation 

"The  VAX/VMS  Guide  to  System  Security"  is  good  example  of  a 
compendium  of  information  that  a  Security  Administrator  needs  to 
know.  It  specifically  addresses  security  issues,  describes  the 
security  implications  when  selecting  system  wide  options, 
recommends  courses  of  action  that  an  administrator  could  take  in 
specific  situations  and  provides  many  examples  that  highlight 
points  made  in  the  text. 


Miscellaneous 

There  is  a  capability  to  limit  user  actions  by  removing  commands 
that  are  available  to  users.  This  can  be  done  on  a  user-by-user 
basis  or  on  a  system-wide  basis. 

There  is  a  facility  availability  that  permits  an  administrator 
the  ability  to  limit  space/time  consumption  (resources)  on  the 
machine.  This  will  help  protect  against  certain  Denial  of 
Service  problems  that  can  occur. 
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EVALUATED  HARDWARE  COMPONENTS 

The  evaluated  hardware  set  includes  the  following  stand-alone 
processors : 

11/725 

11/730 

11/750 

11/751 

11/780 

11/782 

11/785 

8200 

8600 

8650 

Norden  Systems,  Inc.  MIL  VAX  I 
Norden  Systems,  Inc.  MIL  VAX  II 
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EVALUATED  SOFTWARE  COMPONENTS 


The  following  TCB  software  listing  was  provided  by  Digital  to  the 
evaluation  team: 

This  is  a  directory  listing  of  a  VMS  V4.3  system  disk,  annotated 
to  give  the  sensitivity  and  purpose  of  all  files  on  the  system 
disk. 

There  are  seven  levels  of  sensitivity,  presented  in  rough  order. 
The  sensitivity  number  is  interpreted  as  follows: 

1 .  Primary  TCB  code . 

Enforces  protection  policy  /  provides  external  interface  to 
the  TCB  (e.g.,  exec,  file  system).  Includes  images  installed 
with  privileges  susceptible  to  external  attack. 

2.  Primary  TCB  data. 

Contents  is  critical  to  the  correct  operation  of  the  TCB 
(e.g.,  the  authorization  database). 

3.  TCB  utility. 

Used  by  the  system  administrator  to  manage  the  TCB.  Does  not 
directly  enforce  security  policy  in  that  its  effective 
actions  are  mediated  by  other  category  (1)  TCB  components, 
but  operates  on  TCB  sensitive  data  (e.g.,  the  authorization 
database),  so  operation  must  be  correct  to  insure  TCB 
integrity  (e.g.,  AUTHORIZE  utility). 

4.  Secondary  TCB  code. 

Does  not  implement  security  policy  or  interface  with  users, 
but  executes  within  the  domain  of  the  TCB  and  therefore  must 
be  correct  to  insure  integrity  of  the  TCB  (e.g.,  device 
drivers).  This  category  contains  some  images  installed  with 
privileges  not  readily  subject  to  external  attack  (e.g., 
CMKRNL) . 

5.  Secondary  TCB  data. 

Data  relevant  to  the  TCB's  operation,  but  not  critical  to  its 
integrity.  Contains  confidential  data  (e.g.,  the  accounting 
and  audit  logs). 
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6.  Secondary  TCB  utility. 

Utilities  likely  to  be  used  by  the  system  administrator  in 
managing  the  system.  Its  effective  actions  are  mediated  by 
category  (1)  TCB  components,  and  it  does  not  operate  on  any 
security  policy  relevant  structures ,  but  incorrect  operation 
could  compromise  the  TCB  (e.g.,  COPY  command).  Includes 
several  shareable  libraries  used  by  category  (1)  and  (4) 
components . 

7.  Not  TCB. 

Not  involved  in  TCB  operations,  and  not  likely  to  be  used  in 
day  to  day  management  of  the  TCB.  This  does  not  mean  that 
category  (7)  components  are  harmless.  A  trojan  horse  planted 
in  any  component  used  at  some  time  by  a  system  administrator 
can  compromise  the  TCB.  Directories  have  been  given  a  rating 
based  on  the  most  sensitive  object  they  contain. 

The  suffixes  "N"  and  "C"  are  used  on  the  sensitivity  labels  to 
indicate  that  the  component  is  specific  to  networking  or 
VAXclusters,  respectively. 


The  bracketed  name  given  after  most  .EXE  files  is  the  name  of  the 
facility  under  which  the  listings  for  that  EXE  may  be  found. 


[000000]  1 

000000. DIR  1 

BACKUP . SYS  7 

BADBLK . SYS  5 

BADLOG . SYS  5 

BITMAP. SYS  2 

CONTIN . SYS  7 

CORIMG . SYS  7 

DECNET . DIR  7 

INDEXF .SYS  2 

SYSO.DIR  1 

SYSEXE . DIR  4 

SYSMAINT . DIR  6 

VOLSET . SYS  2 

[SYSO]  1 


Volume  master  file  directory 

Volume  master  file  directory 
Not  used  by  VMS 
Volume  bad  block  file 
Pending  bad  block  file 
Volume  storage  allocation  bitmap 
Volume  set  continuation  file 
Not  used  by  VMS 
User  directory  for  the  default 
DECnet  account 
Volume  index  file 
System  top  level  directory 
Synonym  system  directory  for 
booting 

Field  service  working  directory 
(synonym) 

Volume  set  list 

System  top  level  directory 
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SYSCBI . DIR 

7 

SYSERR . DIR 

5 

SYSEXE . DIR 

1 

SYSHLP . DIR 

7 

SYSLIB.DIR 

1 

SYSMAINT.DIR 

6 

SYSMGR . DIR 

2 

SYSMSG . DIR 

7 

SYSTEST.DIR 

6 

SYSUPD.DIR 

3 

[SYSO. SYSERR] 

5 

ERRLOG . SYS 

5 

ERRSNAP . COM 

6 

[SYSO. SYSEXE] 

1 

ACC . EXE 

[ACC] 

3 

ACLEDT . EXE 

[ACLEDT] 

3 

ANALIMDMP . EXE 

[IMGDMP] 

4 

ANALYZBAD . EXE 

[BAD] 

6 

ANALYZOB J . EXE 

[ANALYZ] 

7 

ANALYZRMS . EXE 

[ ANALYZ ] 

7 

AUTHORIZE . EXE 

[UAF] 

3 

AUTOGEN. PAR 

2 

BACKUP . EXE 

[BACKUP] 

3 

BADBLOCK . EXE 

[BADBLK] 

4 

BOOT 5 8 . EXE 

[BOOTS] 

4 

BOOTBLOCK . EXE 

[BOOTS] 

4 

CDU . EXE 

[CDU] 

1 

CHECKSUM . EXE 

[UTIL32] 

6 

CIA. EXE 

[CLIUTL] 

3 

CLUSTRLOA . EXE 

[SYSLOA] 

4C 

CNDRIVER . EXE 

[DRIVER] 

4C 

CONFIGURE . EXE 

[ BOOTS ] 

4 

CONINTERR.EXE 

[DRIVER] 

4 

Computer  based  instruction 
software 
Error  log  files 
Operating  system  executable 
images 

Help  libraries 
Operating  system  libraries 
Field  service  working  directory 
System  manager  default  directory 
System  message  files 
System  regression  tests 
System  update  tools 

Error  log  files 

System  error  log  file 
VAX  8600  CPU  snapshot  copy 
facility 

Operating  system  files 

Accounting  log  analysis  utility 
Access  control  list  editor 
Process  dump  analyzer 
( ANALYZE / PROCESS_DUMP ) 

Bad  block  analysis  utility 
(ANALYZE /MEDIA) 

Object  file  analysis  utility 
(ANALYZE/ ON JECT) 

RMS  record  analysis  utility 
(ANALYZE /RMS) 

Authorization  database 
maintenance  utility 
SYSGEN  parameter  input  to 
AUTOGEN 

Backup/ restore  facility 
Dynamic  bad  block  analysis 
facility 

TU58  conversational  boot  utility 
Primary  bootstrap  for  VAX-11/750 
Command  definition  utility 
(SET  COMMAND) 

Software  update  checksum  utility 
Intrusion  list  display  (SHOW 
INTRUSION  /  DELETE /INTRUSION) 
Cluster  management  kernel 
DECnet  driver  for  the  Cl 
MSCP  controller  configurator 
Connect  to  interrupt  driver 
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CONVERT . EXE 

[CONV] 

7 

COPY . EXE 

[COPY] 

6 

CRDRIVER . EXE 

[DRIVER] 

4 

CREATE . EXE 

[CLIUTL] 

6 

CREATEFDL . EXE 

[FDL] 

7 

CSP.EXE 

[SYSLOA] 

4C 

CTDRIVER.EXE 

[RTPAD] 

4N 

CVDRIVER . EXE 

[DRIVER] 

4 

CVTNAF . EXE 

[UAF] 

3 

CVTUAF . EXE 

[UAF] 

3 

DBDRIVER . EXE 

[DRIVER] 

4 

DCL . EXE 

DCLDEF . STB 

[DCL] 

1 

7 

DDDRIVER . EXE 

[DRIVER] 

4 

DELETE . EXE 

[DELETE] 

6 

DIFF.EXE 

[DIF] 

7 

DIRECTORY . EXE 

[DIR] 

6 

DISKQUOTA.EXE 

[DISKQ] 

3 

DISMOUNT . EXE 

[DISMOUl 

6 

DLDRIVER . EXE 

[DRIVER] 

4 

DMDRIVER . EXE 

[DRIVER] 

4 

DQDRIVER . EXE 

[DRIVER] 

4 

DRDRIVER . EXE 

[DRIVER] 

4 

DSRINDEX . EXE 

[RUNOFF] 

7 

DSRTOC . EXE 

DTR . COM 

[RUNOFF] 

7 

7N 

DTRECV . EXE 

[DTSDTR] 

7N 

DTSEND . EXE 

[DTSDTR] 

7N 

DUDRIVER.EXE 

[DRIVER] 

4 

DUMP . EXE 

[DUMP] 

7 

DXDRIVER.EXE 

[DRIVER] 

4 

DYDRIVER.EXE 

[DRIVER] 

4 

DZDRIVER.EXE 

[TTDRVR] 

4 

EDF . EXE 

[EDF] 

7 

EDT . EXE 

[EDT] 

6 

ERF . EXE 

[ERF] 

6 

ERFBRIEF . EXE 

[ERF] 

6 

ERFBUS . EXE 

[ERF] 

6 

ERFDISK.EXE 

[ERF] 

6 

ERFINICOM . EXE 

[ERF] 

6 

ERFPR0C1.EXE 

[ERF] 

6 

RMS  CONVERT  utility 
COPY  utility 
Card  reader  driver 
CREATE  utility 
(CREATE.  CREATE /DIRECTORY) 
CREATE/FDL  utility 
Cluster  server  process 
DECnet  Cterm  virtual  terminal 
driver 

VAX  8600  console  RL02  driver 
NETUAF  V3/V4  conversion  utility 
SYSUAF  V3/V4  conversion  utility 
RP04/5/6  disk  driver 
DCL  command  language  interpreter 
DCL  data  structure  definitions 
TD58  driver 
DELETE  utility 
File  compare  utility 
DIRECTORY  utility 
Disk  quota  management  utility 
DISMOUNT  command 
RLOl/2  disk  driver 
RK06/7  disk  driver 
VAX-1 1/730  integrated  disk 
driver 

RM03/5/RP07  disk  driver 
RUNOFF  index  utility 
RUNOFF  table  of  contents 
utility 

DECnet  logical  link  test 
procedure 

DECnet  logical  link  test 
receiver 

DECnet  logical  link  test 
transmitter 
DSA  disk  class  driver 
DUMP  utility 
Console  RXOl  driver 
RX02  disk  driver 
DZll  terminal  port  driver 
EDIT/FDL  file  description  editor 
EDT  editor 

Error  log  analysis  utility 
(ANALYZE /ERROR) 

Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
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ERFPROC2 . EXE 

[ERF] 

6 

ERFPROC3 . EXE 

[ERF] 

6 

ERFPR0C4 . EXE 

[ERF] 

6 

ERFPROC5 . EXE 

[ERF] 

6 

ERFRLTIM.EXE 

[ERF] 

6 

ERFSUMM . EXE 

[ERF] 

6 

ERFTAPE . EXE 

[ERF] 

6 

ERFUVAX . EXE 

[ERF] 

6 

ERFVX8600 . EXE 

[ERF] 

6 

ERRFMT . EXE 

[ERRFMT] 

4 

ERR SNAP . EXE 

[ERRFMT] 

6 

ESDRIVER . EXE 

[DRIVER] 

4 

EVL.COM 

6N 

EVL.EXE 

[EVL] 

4N 

EXCHANGE . EXE 

[EXCHNG] 

6 

F11AACP.EXE 

[FllA] 

1 

F11BXQP.EXE 

[FllX] 

1 

FAL . COM 

6N 

FAL . EXE 

[FAL] 

6N 

FILESERV . EXE 

[FllX] 

4C 

FPEMUL.EXE 

[EMULAT] 

4 

FYDRIVER . EXE 

[DUP] 

4 

HLD . COM 

7N 

HLD . EXE 

[HLD] 

7N 

HSCPAD.EXE 

[DUP] 

6 

IMGDEF . STB 

7 

INIT.EXE 

[INIT] 

1 

INPSMB . EXE 

[INPSMB] 

1 

INSTALL . EXE 

[INSTAL] 

3 

JOBCTL . EXE 

[JOBCTL] 

1 

LADRIVER.EXE 

[DRIVER] 

4 

LALOAD.EXE 

[MCLDR] 

6 

LALOADER . EXE 

[MCLDR] 

4 

LATCP . EXE 

[LAT] 

6N 

LCDRIVER . EXE 

[DRIVER] 

4 

LIBRARIAN . EXE 

[LIBRAR] 

6 

LINK . EXE 

[LINKER] 

6 

LOGINOUT . EXE 

[LOGIN] 

1 

LPDRIVEP. .  EXE 

[DRIVER] 

4 

LTDRIVER . EXE 

[LAT] 

4N 

MACR032 . EXE 

[MACRO] 

7 

Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  analysis  subcomponent 
Error  log  process 
VAX  8600  CPU  snapshot  copy 
utility 

LANCE  chip  (integrated  ethernet 
adaptor)  port  driver 
DECnet  event  logger  procedure 
DECnet  event  logger 
File  exchange  utility 
Files-11  level  1  file  system 
Files-11  level  2  file  system 
DECnet  file  server  command  file 
DECnet  file  server 
Cluster  file  system  cache  server 
Floating  point  emulator  for 
microvax 
DUP  class  driver 
(used  by  SET  HOST/HSC) 

RSX  down-line  task  load 
procedure 

RSX  down-line  task  load  process 
HSC  remote  console  utility 
(SET  HOST/HSC) 

Image  header  format  definitions 
Volume  initialization  utility 
Batch  job  input  symbiont 
Installed  file  maintenance 
utility 

Batch/print  job  controller 
LPAll  lab  peripheral  driver 
LPAll  microcode  load  utility 
LPAll  microcode  loader  process 
LAT  control  program 
DMF32  line  printer  driver 
Object /macro/help/text  librarian 
utility 
Linker 

LOGIN  ^  LOGOUT  utility 
LPll  line  printer  driver 
LAT- 11  terminal  port  driver 
Macro  assembler 
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MAIL . COM 

7 

MAIL . EXE 

[MAIL] 

1 

MAILEDIT . COM 

7 

MBXDRIVER . EXE 

[DRIVER] 

4 

MESSAGE . EXE 

[MSGFIL] 

7 

MIRROR . COM 

7N 

MIRROR . EXE 

[MIRROR] 

7N 

MODPARAMS . DAT 

2 

MOM . COM 

6N 

MOM . EXE 

[MOM] 

4N 

MONITOR . EXE 

[MONTOR] 

1 

MP . EXE 

[MP] 

4 

MP. STB 

7 

MSCP . EXE 

[MSCP] 

4C 

MTAAACP . EXE 

[MTAACP] 

1 

NCP . EXE 

[NCP] 

3N 

NDDRIVER . EXE 

[NETACP] 

4N 

NETACP . EXE 

[NETACP] 

IN 

NETCIRC . DAT 

2N 

NETCONF . DAT 

2N 

NETDEF . STB 

7N 

NETDRIVER . EXE 

[NETACP] 

4N 

NETLINE . DAT 

2N 

NETLOGING . DAT 

2N 

NETNODE . DAT 

2N 

NETOBJECT . DAT 

2N 

NETSERVER . COM 

6N 

NETSERVER . EXE 

[NETACP] 

6N 

NETUAF . DAT 

2N 

NICONFIG . COM 

6N 

NICONFIG.EXE 

[NICNF] 

4N 

NML . COM 

6N 

NML . EXE 

[NML] 

6N 

NODRIVER . EXE 

[DRIVER] 

4N 

NOTICE . TXT 

7 

Mail  receiver  DECnet  task 
MAIL  facility 

MAIL  SEND/EDIT  command  file 
Shared  memory  mailbox  driver 
Message  compiler  utility 
DECnet  link  loopback  test 
procedure 

DECnet  link  loopback  test 
process 

SYSGEN  parameters  input  to 
AUTOGEN 

DECnet  down  line  system  load 
procedure 

DECnet  down  line  system  load 
process 

MONITOR  utility 
VAX-11/782  multi-processor 
support 

MP  support  symbol  table 
MSCP  server 
Magtape  file  system 
Network  control  utility 
DECnet  down  line  load  and 
loopback  class  driver 
DECnet  protocol  ACP 
DECnet  circuit  database 
DECnet  configurator  database 
Network  structures  symbol  table 
DECnet  protocol  driver 
DECnet  line  database 
DECnet  logging  database 
DECnet  node  database 
DECnet  object  database 
DECnet  general  purpose  listener 
procedure 

DECnet  general  purpose  listener 
process 

DECnet  proxy  file  (network 
authorization  database) 
Ethernet  module  configurator 
procedure 

Ethernet  module  configurator 
process 

Network  management  listener 
procedure 

Network  management  listener 
process 

DECutJu  asyuch  line  ciatss  driver 
Public  notice  file 
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OPCCRASH . EXE 

[OPCOM] 

6 

Final  system  shutdown  program 

OPCOM . EXE 

[OPCOM] 

1 

Operator  communications  manager 
(handles  security  audit  log) 

PADRIVER . EXE 

[DRIVER] 

4C 

Cl  port  driver 

PAGEFILE . SYS 

2 

System  paging  file 

PARAMS . DAT 

2 

System  parameters  input  to 
AUTOGEN 

PATCH . EXE 

[PATCH] 

6 

Image  patch  facility 

PDDRIVER . EXE 

[DRIVER] 

4 

Pseudo-disk  driver 
(used  in  TK50  boot) 

PHONE . COM 

7 

PHONE  listener  task  procedure 

PHONE . EXE 

[PHONE] 

7 

Phone  utility 

PRTSMB . EXE 

[PRTSMB] 

4 

Print  symbiont 

PUDRIVER . EXE 

[DRIVER] 

4 

Unibus  port  driver 
(UDA-50,  TU81) 

QUEMAN . EXE 

[CLIUTL] 

6 

Queue  management  utility 
(SET  /  SHOW  QUEUE) 

RECLAIM . EXE 

[CONV] 

7 

ISAM  space  reclamation  utility 
( CONVERT /RECLAIM ) 

REMACP . EXE 

[REM] 

4N 

DECnet  virtual  terminal  protocol 
object 

RENAME . EXE 

[CLIUTL] 

6 

RENAME  utility 

REPLY . EXE 

[OPCOM] 

3 

REPLY  utility 
(REPLY /ENABLE  /DISABLE) 

REQUEST . EXE 

[OPCOM] 

7 

REQUEST  utility 

RIGHTSLIST.DAT 

2 

Rights  database 

RMS . EXE 

[RMS] 

1 

RMS  -  record  management  services 

RMS . STB 

7 

RMS  structure  definitions 

RMSDEF . STB 

7 

RMS  structure  definitions 

RTB . EXE 

[UTIL32] 

6 

Console  bootstrap  update  utility 

RTPAD . EXE 

[RTPAD] 

6N 

DECnet  virtual  terminal  utility 
(SET  HOST) 

RTTDRIVER.EXE 

[DRIVER] 

4N 

DECnet  virtual  terminal  driver 

RUNDET . EXE 

[CLIUTL] 

6 

Run  process  command  utility 

RUNOFF . EXE 

[RUNOFF] 

7 

RUNOFF  text  formatter 

RXDRIVER.EXE 

[DRIVER] 

4 

Console  RX50  disk  driver 

SCSDEF . STB 

7C 

SCS  structure  definitions 

SCSLOA.EXE 

[SYSLOA] 

4C 

Cl  system  communication  facility 

SDA . EXE 

[SDA] 

6 

Crash  dump  analyzer 

SDLNPARSE . EXE 

6 

SDL  pre-compiled  language 
front  end 

SEARCH . EXE 

[UTIL32] 

7 

SEARCH  utility 

SET. EXE 

[CLIUTL] 

1 

SET  commands 

SETPO . EXE 

[CLIUTL] 

1 

SET  PASSWORD  ®  SET  MESSAGE 
commands 

SETPARAMS . DAT 

2 

SYSGEN  parameters  input  to 
AUTOGEN 

SETSHOACL . EXE 

[ACLEDT] 

3 

SET  &  SHOW  ACL  commands 

SHOW . EXE 

[CLIUTL] 

4 

SHOW  commands 
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SHUTDOWN . COM 

6 

SHWCLSTR . EXE 

[CLIUTL] 

1 

SMGBLDTRM . EXE 

tSMGRTL] 

6 

SMGMAPTRM . EXE 

[SMGRTL] 

6 

SMGTERMS . TXT 

7 

SORTMERGE . EXE 

[S0RT32] 

7 

SRTTRN . EXE 

[SORT32] 

7 

STABACCOP . EXE 

[BACKUP] 

6 

STABACKUP . EXE 

[BACKUP] 

3 

STACONFIG.EXE 

[BOOTS] 

4 

STANDCONF . EKE 

[ BOOTS ] 

4 

STARTUP . COM 

3 

STARTUP . INS 

3 

STASYSGEN . EXE 

[BOOTS] 

6 

STOPREM.EXE 

[REM] 

6N 

SUBMIT.EXE 

[CLIUTL] 

6 

SUMSLP . EXE 

[SUM] 

6 

SWAPFI^iE .  SYS 

2 

SYS . EXE 

[SYS] 

1 

SYS . MAP 

7 

SYS  STB 

6 

SYSALF . DAT 

2 

SYSBOOT . EXE 

[BOOTS] 

4 

SYSDEF . STB 

7 

SYSDUMP . DMP 

5 

SYSGEN . EXE 

[BOOTS] 

3 

SYSINIT.EXE 

[SYSINI] 

4 

SYSLOA730 . EXE 

[SYSLOA] 

4 

SYSLOA750 . EXE 

[SYSLOA] 

4 

SYSLOA780 . EXE 

[SYSLOA] 

4 

SYSLOA790 . EXE 

[SYSLOA] 

4 

SYSLOA8SS.EXE 

[SYSLOA] 

4 

SV.slOAUVI  .  EXE 

[SYSLOA] 

4 

SYSLOAUV2 . EXE 

[SYSLOA] 

4 

SYSUAF . DAT 

2 

SYSUAF . RL2 

6 

TECO . EXE 

[TECO] 

7 

TERMTABLE . EXE 

[SMGRTL] 

7 

TERMTABLE . TXT 

7 

TFDRIVER . EXE 

[DRIVER] 

4 

SHUTDOWN  facility 
SHOW  CLUSTER  utility 
Terminal  characteristics  table 
compiler 

Terminal  characteristics  table 
installation 

Terminal  characteristics  table 
source 

SORT /MERGE  utility 
SORT/MERGE  spec  file  translator 
Build  stand-alone  BACKUP  kit 
Stand-alone  BACKUP 
MSCP  controller  configurator 
during  boot 

MSCP  controller  configurator 
for  s/a  BACKUP 
System  startup  command  file 
Startup  command  file  during 
installation 

System  configuration  for 
stand-alone  BACKUP 
Utility  to  shut  down  REMACP 
PRINT  /  SUBMIT  commands 
EDIT/SUM  utility 
System  swap  file 
System  kernel 
System  link  map 
System  symbol  table 
Auto-login  control  file 
Secondary  system  bootstrap 
System  data  structure 
definitions 

System  crash  dump  file 
System  configuration  utility 
System  initialization  process 
CPU  specific  kernel  code 
CPU  specific  kernel  code 
CPU  specific  kernel  code 
CPU  specific  kernel  code 
CPU  specific  kernel  code 
CPU  specific  kernel  code 
CPU  specific  kernel  code 
System  authorization  file 
Template  system  authorization 
file 

TECO  text  editor 
Terminal  characteristics  table 
User  terminal  char  table  source 
TU78  magtape  driver 
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TMDRIVER.EXE 
TPU . EXE 
TSDRIVER.EXE 
TTDRIVER . EXE 
TUDRIVER . EXE 
TYPE . EXE 
UNLOCK . EXE 
VAXEMUL . EXE 

VAXVMSSYS . PAR 
VERIFY.EXE 


VMB . EXE 
VMOUNT . EXE 
VMSHELP . EXE 
WRITEBOOT.EXE 
XADRTVEP.EXE 

XDDRIVER . EXE 

XEDRIVER . EXE 
XFDRIVER . EXE 

XFLOADER . EXE 
XGDRIVER.EXE 
XMDRIVER . EXE 
XWDRIVER.EXE 
YCDRIVER . EXE 
YFDRIVER . EXE 

[SYSQ. SYSHLP] 


ACLEDT . HLB 
ANLRMSHLP . HLB 
DEBUGHLP . HLB 
DISKQUOTA.HLB 
EDFHLP . HLB 
EDTHELP . HLB 
EDTVT100.DOC 
EDTVT52 . DOC 
EXAMPLES . DIR 
EXCHNGHLP . HLB 
HELPLIB . HLB 
INSTALHLP . HLB 
LATCP . HLB 
MAILHELP.HLB 
MNRHELP . HLB 
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[DRIVER] 

[TPU] 

[DRIVER] 

[  TTDRVR ] 

[DRIVER] 

[CLIUTL] 

[CLIUTL] 

[EMULAT] 


[VERIFY] 


[BOOTS] 

[MOUNT] 

[HELP] 

[BOOTS] 

[DRIVER] 

[DRIVER] 

[DRIVER] 

[DRIVER] 

[MCLDR] 

[DRIVER] 

[DRIVER] 

[DRIVER] 

[TTDRVR] 

[ TTDRVR ] 


4  TE16/TU77  magtape  driver 

6  TPU  text  editor 
4  TS11/TU80  magtape  driver 

4  Terminal  class  driver 
4  DSA  tape  class  driver 

6  TYPE  utility 

7  UNLOCK  command 

4  Subsetted  instruction  emulator 
for  microvax 

2  Current  SYSGEN  parameters 

3  File  structure  verification 

utility 

(ANALYZE/DISK) 

4  Primary  system  bootstrap 

6  MOUNT  command 

7  HELP  facility 

6  Write  primary  boot  block 

4  DRll-W  general  purpose  interface 
driver 

4N  DMPll/DMVll *multi-drop  sync  line 
driver 

4N  Ethernet  port  driver 
4  DR32  general  purpose  interface 
driver 

4  DR32  microcode  loader 
4N  DMF32  sync  line  driver 
4N  DMCll/DMRll  sync  line  driver 
4N  DUPll  bisync  line  driver 
4  DMF32  terminal  port  driver 
4  DHUll/DHVll  terminal  port  driver 

7  Help  libraries  and  on  line 

documentation 
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NCPHELP.HLB 
PATCHHELP . HLB 
PHONEHELP . HLB 
SDA . HLB 
SHWCLHELP . HLB 
SYSGEN . HLB 
TECO . HLB 
TPUHELP.HLB 
UAFHELP . HLB 
VMSTLRHLP . HLB 

[ SYSO . SYSHLP . EXAMPLES]  7  System  coding  examples 

ADDRIVER . MAR 
CONNECT . COM 
DOD_ERAPAT . MAR 
DRCOPY . PRM 
BRCOPYBLD . COM 
DRMAST . MAR 
DRMASTER . FOR 
DRSLAVE . FOR 
DRSLV . MAR 
DTE_DF03 . MAR 
GBLSECUFO . MAR 
LABCHNDEF . FOR 
LABIO.OPT 
LABIOACQ.FOR 
LABIOCIN . MAR 
LABIOCIN.OPT 
LABIOCOM.FOR 
LABIOCOMP . COM 
LABIOCON . FOR 
LABIOLINK . COM 
LABIOPEAK . FOR 
LABIOSAMP.FOR 
LABIOSEC . FOR 
LABIOSTAT.FOR 
LABIOSTRT.COM 
LABMBXDEF . FOR 
LBRDEMO . COM 
LBRDEMO . FOR 
LBRMAC . MAR 
LPATEST.FOR 
LPMULT . B32 
MAILCOMPRESS . COM 
MAILCVT.COM 
MAILUAF . COM 
MONITOR.COM 
MONSUM.COM 
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MSCPMOUNT . COM 
PEAK . FOR 
SCRFT . MAR 
SUBMON . COM 
SYSGTTSTR . MSG 
TDRIVER.MAR 
TESTLABIO.FOR 
USSDISP.MAR 
USSLNK.COM 
USSTEST.MAR 
USSTSTLNK.COM 
XADRIVER . MAR 
XALINK . MAR 
XAMES SAGE. MAR 
XATEST . COM 
XATEST.FOR 
XIDRIVER . MAR 

[SYSO.SYSLIB] 

ACLEDIT.INI 
ADARTL . EXE 
BASRTL . EXE 
BASRTL2 . EXE 
CDDSHR . EXE 

CLIMAC . REQ 
COBRTL.EXE 
CONVSHR . EXE 
CRFSHR.EXE 
DBGSSISHR.EXE 

DCLTABLES . EXE 
DCXSHR . EXE 
DEBUG . EXE 
DEBUG . TPU 
DELTA . EXE 
DELTA . OBJ 

DISMNTSHR.EXE 
DTE_DF03 . EXE 
DTE_DF112.EXE 

DYNSWITCH . EXE 

EDTSECINI.GBL 

EDTSECINI .TPU 
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[ADARTL] 

[BASRTL] 

[BASRTL] 

[CDD] 


[COBRTL] 

[CONV] 

[CRF] 

[DEBUG] 

[CLD] 

[DCX] 

[DEBUG] 

[DELTA] 


[DISMOU] 

[RTPAD] 

[RTPAD] 

[CLIUTL] 


1  System  libraries 

6  ACL  editor  initialization  file 

7  ADA  run  time  library 

6  BASIC  run  time  library 

7  BASIC  run  time  library 

7  Common  data  dictionary  stub 
module 

7  DCL  call  structure  definitions 
7  COBOL  run  time  library 
6  Callable  CONVERT  facility 
6  Cross  reference  facility 

1  Debugger  system  service 

intercept 

2  DCL  command  interpreter  tables 

6  Data  compression  facility 

7  Symbolic  debugger 

7  Debugger  for  TPU  procedures 
6  Privileged  mode  debugger 

6  Linkable  privileged  mode 

debugger 

1  DISMOUNT  facility 

7  DF03  autodialer  for  SET  HOST/DTE 

7  DF112  autodialer  for 

SET  HOST /DTE 

IN  Switch  terminal  line  to  async 
DECnet 

6  EDT  emulator  TPU  procedure 

(compiled) 

7  EDT  emulator  TPU  procedure 

( source ) 
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EDTSHR . EXE 

tEDT] 

6 

ENCRYPSHR . EXE 

[ENCRYP] 

6 

ERFCOMMON . EXE 

[ERF] 

6 

ERFCTLSHR . EXE 

[ERF] 

6 

ERFLIB . TLB 

6 

ERFSHR . EXE 

[ERF] 

6 

ERFSHR2 . EXE 

[ERF] 

6 

EVESECINI -GBL 

6 

EVESECINI.TPU 

7 

FDLSHR . EXE 

[FDL] 

6 

FORDEF . FOR 

7 

FORIOSDEF . FOR 

7 

FORRTL.EXE 

[FORRTL] 

6 

IMAGELIB.OLB 

7 

IMGDMP . EXE 

[IMGDMP] 

4 

LBRSHR . EXE 

[LBR] 

6 

LIB . MLB 

7 

LIB.REQ 

7 

LIBDEF . FOR 

7 

LIBRTL.EXE 

[LIBRTL] 

6 

LIBRTL2 . EXE 

[LIBRTL] 

6 

MOUNTSHR . EXE 

[MOUNT] 

1 

MTHDEF .  F‘OR 

7 

MTHRTL . EXE 

[MTHRTL] 

6 

NMLSHR . EXE 

[NML] 

3N 

PASRTL.EXE 

[PASRTL] 

6 

PLIRTL.EXE 

[PLIRTL] 

6 

RPGRTL . EXE 

[RPGRTL] 

7 

SCNRTL . EXE 

[SCNRTL] 

7 

SCRSHR . EXE 

[VMSLIB] 

6 

SECURESHR.EXE 

[ LOADS S] 

1 

SIGDEF.FOR 

7 

SMBSRVSHR . EXE 

[PRTSMB] 

4 

SMGSHR . EXE 

[SMGRTL] 

6 

SORTSHR . EXE 

[ SORT32 ] 

6 

STARLET . MLB 

7 

STARLET . OLB 

7 

STARLET . REQ 

7 

STARLETSD.TLB 

7 

SUMSHR . EXE 

[SUM] 

6 

TPAMAC . REQ 

7 

TPUSECINI.GBL 

6 

TPUSHR.EXE 

[TPU] 

6 
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Callable  EDT  editor 
Encryption  facility  stub  module 
Error  log  analysis  component 
Error  log  analysis  component 
Error  log  supported  device  list 
Error  log  analysis  component 
Error  log  analysis  component 
EVE  emulator  TPU  procedure 
(compiled) 

EDT  emulator  TPU  procedure 
(source) 

Callable  FDL  utility 
Fortran  OTS  message  symbols 
Fortran  OTS  I/O  message  symbols 
Fortran  run  time  library 
Shareable  image  library 
Process  dump  facility 
Callable  librarian 
System  macro  library 
BLISS  system  macro  library 
Fortran  library  symbol 
definitions 

General  run  time  library 
General  run  time  library 
MOUNT  facility 

Fortran  math  symbol  definitions 
Common  math  library 
Callable  NML  functions 
PASCAL  run  time  library 
PL/ I  run  time  library 
RPG  run  time  library 
SCAN  language  run  time  library 
Screen  management  package  (old) 
Security  system  services 
Fortran  condition  symbol 
definitions 

Symbiont  shareable  services 
Screen  management  package  (new) 
Callable  sort  facility 
System  macro  library 
System  object  library 
System  BLISS  macro  library 
System  interface  definitions  - 
SDL  intermediate 
Callable  EDIT/SUM  editor 
TPARSE  BLISS  macro  library 
Default  TPU  initialization 
(compiled) 

TPU  callable  text  editor 
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TRACE . EXE 

[TRACE] 

7 

Program  taceback  facility 

VAXCCURSE . OLB 

7 

C  language  terminal  support 
library 

VAXCRTL.EXE 

[CRTL] 

7 

C  run  time  library 

VAXCRTL.OLB 

7 

C  linkable  run  time  library 

VAXCRTLG . OLB 

7 

C  linkable  run  time  library 

VMSRTL . EXE 

[VMSRTL] 

7 

Old  run  time  library  entry 
vectors 

XFDEP . FOR 

7 

Fortran  DR32  symbols 

[SYSO.SYSMGR] 

2 

System  manager  working  directory 

ACCOUNTNG . DAT 

5 

Accounting  log  file 

ALFMAINT . COM 

3 

Auto-login  file  (SYSALF) 
maintenance  utility 

EVL.LOG 

5N 

DECnet  event  log 

LOADNET . COM 

6N 

DECnet  process  startup  command 
file 

LPA11STRT.COM 

6 

LPAll  startup  command  file 

LTLOAD . COM 

6N 

LAT  startup  command  file 

MAKEROOT . COM 

6C 

Build  system  root  on  common 
cluster  system  disk 

NETCONFIG.COM 

6N 

Configure  network  database 

OPERATOR . LOG 

5 

Operator  log  file  (contains 
security  audit  messages) 

RTTLOAD . COM 

6N 

Load  DECnet  virtual  terminal 
driver 

SECAUDIT . COM 

3 

Analyze  security  audit  log 

STARTNET . COM 

6N 

Start  up  DECnet 

SYCONFIG.COM 

6 

Site  specific  configuration 
command  file 

SYSHUTDWN . COM 

6 

Site  specific  shutdown  file 

SYSTARTUP . COM 

3 

Site  specific  startup  command 
file 

VMSIMAGES.COM 

3 

Install  images  during  system 
startup 

VMSIMAGES.DAT 

2 

List  of  installed  images 

[SYSO.SYSMSG] 

ADAMSG . EXE 
CLIUTLMSG . EXE 
DBGTBKMSG . EXE 
FILMNTMSG.EXE 
NETWRKMSG . EXE 
PASMSG . EXE 
PLIMSG.EXE 
PRGDEVMSG.EXE 
RPGMSG.EXE 

[ADARTL] 

[MSGFIL] 

[MSGFIL] 

[MSGFIL] 

[MSGFIL] 

[PASRTL] 

[PLIRTL] 

[MSGFIL] 

[RPGRTL] 

7 

Shareable  message  files 
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SCNMSG . EXE  [ SCNRTL 1 

SHRIMGMSG.EXE  [MSGFIL] 

SYSMGTMSG.EXE  [MSGFIL] 

SYSMSG.EXE  [MSGFIL] 

TPUMSG.EXE  [TPU] 

VAXCMSG.EXE  [CRTL] 

[SYSO. SYSTEST]  6  System  test  facility 

TCNTRL . CLD 
UETCLIGOO . COM 
UETCLIGOO . DAT 
UETCLIGOO . EXE  [ UETPSY ] 

UETCOMSOO.EXE  [UETP] 

UETDISKOO.EXE  [UETP] 

UETDMPFOO . EXE  [ UETP ] 

UETDNETOO . COM 
UETDNETOO . DAT 
UETDR1WOO.EXE  [UETP] 

UETDR7800.EXE  [UETPSY] 

UETF0RT01.DAT 
UETFORTO 1 . EXE  [ UETP ] 

UETFORT02 . EXE  [ UETP ] 

UETFORT03 . EXE  [ UETP ] 

UETINITOO.EXE  [UETPSY] 

UETINIT01.EXE  [UETPSY] 

UETLOADOO . DAT 
UETL0AD02 . COM 
UETL0AD03 . COM 
UETLOAD04 . COM 
UETLOAD05.COM 
UETLOAD06 . COM 
UETLOAD07 . COM 
UETLOAD08 . COM 
UETLOAD09.COM 
UETLOAD10.COM 
UETLOADll.COM 
UETLPAKOO . EXE  [ UETP ] 

UETMA7800 . EXE  [ UETPSY ] 

UETMEMY01.EXE  [UETPSY] 

UETNETSOO.EXE  [UETP] 

UETP . COM 

UETPHASOO.EXE  [UETP] 

UETRSXFOR . EXE 
UETSUPDEV . DAT 
UETTAPEOO . COM 
UETTAPEOO . EXE  [ UETP ] 

UETTTYSOO . EXE  [ UETP ] 

UETUNASOO.EXE  [UETP] 
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[SYSO.SYSUPD] 

AUTOGEN . COM 
BLISSREQ.TLR 
BOOTBLDR . COM 
BOOTUPD . COM 
CONSCOPY . COM 
CVTNAF . COM 

CVTUAF . COM 

DECNET . TLR 
DEVE1.0P .  TLR 
DXCOPY . COM 

EXAMPLES. TLR 
FILETOOLS . TLR 
HELP . TLR 
LIBDECOMP . COM 
LIBRARY . TLR 
MANAGER . TLR 
MISCTOOLS . TLR 
QUEUES. TLR 
REQUIRED. TLR 
SETDEFBOO . COM 
SPKITBLD.COM 
STABACKIT . COM 
SWAPFILES.COM 

TEXTTOOLS . TLR 
UETP . TLR 
VMSINSTAL.COM 
VMSKITBLD . COM 
VMSKITBLD . DAT 
VMSTAILOR . COM 

VMSUPDATE . COM 


[SYSEXE] 


SYSBOOT.EXE 
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3  System  update  tools 

3  Generate  SYSGEN  parameters 

6  System  tailoring  control  file 
6  Build  782  console  floppies 
6  Update  console  boot  medium 
6  Copy  console  boo^:;  medium 
6N  Run  network  authorization  file 
conversion 

6  Run  system  authorization  file 
conversion 

6  System  tailoring  control  file 

6  System  tailoring  control  file 

6  Copy  files  between  console 

medium  and  working  directory 
6  System  tailoring  control  file 

6  System  tailoring  control  file 

6  System  tailoring  control  file 

6  Decompress  system  libraries 
6  System  tailoring  control  file 

6  System  tailoring  control  file 

6  System  tailoring  control  file 

6  System  tailoring  control  file 

6  System  tailoring  control  file 

6  Set  default  boot  command  file 

6  Build  software  product  kit 
6  Build  standalone  BACKUP  kit 
6  Adjust  page,  swap,  and  dump  file 
sizes 

6  System  tailoring  control  file 

6  System  tailoring  control  file 

6  Install  VMS  product  updates 
6  Build  a  VMS  system  disk 
6  Data  file  for  VMSKITBLD.COM 
6  Tailor  limited  environment  VMS 
system 

6  Install  VMS  product  updates 
(obsolete) 

4  Top  level  dir  for  compatibility 

with  old  bootstraps 

4  Secondary  system  bootstrap 
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VAX/VMS  Privileges 

VAX/VMS  PRIVILEGES 

VMS  has  thirty-five  privileges  that  can  be  associated  with  a 
process.  The  descriptions  below  were  extracted  from  "Guide  to 
VAX/ VMS  System  Securty" ,  Appendix  A. 

1.  [NO]  ACNT 

[Disallows] /allows  the  process  to  create  processes  for  which  no 
accounting  messages  are  written. 

2.  [NO]  ALLSPOOL 

[Disallows] /allows  the  process  to  allocate  spooled  devices. 

3.  [NO]  ALTPRI 

[Disallows] /allows  the  process  to  set  priority  values. 

4.  [NO]  BUGCHK 

[Disallows] /allows  the  process  to  make  bug  check  error  log 
entries . 

5.  [NO]  BYPASS 

[Disallows] /allows  the  process  to  bypass  ACL  and  UIC  protection. 

6.  [NO]  CMEXEC 

[Disallows] /allows  the  process  to  change  its  mode  to  executive. 

7.  [NO]  CMKRNL 

[Disallows] /allows  the  process  to  change  its  mode  to  kernel. 

8.  [NO]  DETACH 

[Disallows] /allows  the  process  to  create  detached  processes. 

9.  [NO]  DIAGNOSE 

[Disallows] /allows  the  process  to  issue  diagnostic  I/O  requests. 

10.  [NO]  EXQUOTA 

[Disallows] /allows  the  process  to  exceed  its  quota. 
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11.  [NO]  GROUP 

[Disallows] /allows  the  process  to  control  other  processes  in  the 
same  group. 

12.  [NO]  GRPNAM 

[Disallows] /allows  the  process  to  place  names  in  the  group 

logical  name  table. 

13.  [NO]  GRPPRV 

[Disallows] /allows  the  process  to  access  files  in  its  own  group 
with  all  the  access  rights  granted  to  the  system  category  of  user 
for  those  files. 

14.  [NO]  LOG_IO 

[Disallows] /allows  the  process  to  issue  logical  I/O  requests  to  a 
device . 

15.  [NO]  MOUNT 

[Disallows] /allows  the  process  to  issue  a  mount  volume  QIO 

request . 

16.  [NO]  NETMBX 

[Disallows] /allows  the  process  to  create  a  network  device. 

17.  [NO]  OPER 

[Disallows] /allows  the  process  to  perform  operator  functions. 

18.  [NO]  PFNMAP 

[Disallows] /allows  the  process  to  create  or  delete  sections 

mapped  by  page  frame  number. 

19.  [NO]  PHY_IO 

[Disallows] /allows  the  process  to  issue  physical  I/O  requests  to 
a  device. 

20.  [NO]  PRMCEB 

[Disallows] /allows  the  process  to  create  permanent  common  event 
flag  clusters. 
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21.  [NO]  PRMGBL 

[Disallows] /allows  the  process  to  create  permanent  global 
sections . 

22.  [NO]  PRMMBX 

[Disallows] /allows  the  process  to  create  permanent  mailboxes. 

23.  [NO]  PSWAPM 

[Disallows] /allows  the  process  to  alter  its  swap  mode. 

24.  [NO]  READALL 

[Disallows] /allows  the  process  to  bypass  existing  restrictions 
that  would  otherwise  prevent  the  process  from  reading  a  file. 

25.  [NO]  SECURITY 

[Disallows] /allows  the  process  to  perform  security-related 
functions  such  as  enabling  or  disabling  security  audits  or 
setting  the  system  password. 

26.  [NO]  SETPRV 

[Disallows] /allows  the  process  to  create  processes  with  higher 
privileges . 

27.  [NO]  SHARE 

[Disallows] /allows  the  process  to  assign  a  channel  to  a  device, 
even  if  the  channel  is  allocated  to  another  process  or 
subprocess . 

28.  [NO]  SHMEM 

[Disallows] /allows  the  process  to  create  or  delete  data 
structures  in  shared  memory. 

29.  [NO]  SYSGBL 

[Disallows] /allows  the  process  to  create  system  global  sections. 

30.  [NO]  SYSLCK 

[Disallows] /allows  the  process  to  request  locks  on  system-wide 
resources . 
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31.  [NO]  SYSNAM 

[Disallows] /allows  the  process  to  place  names  in  the  system 
logical  name  table. 

32.  [NO]  SYSPRV 

[Disallows] /allows  access  to  files  and  other  resources  as  if  the 
user  has  a  system  UIC. 

33.  [NO]  TMPMBX 

[Disallows] /allows  the  process  to  create  temporary  mailboxes. 

34.  [NO]  VOLPRO 

[Disallows] /allows  the  process  to  override  volume  protection. 

35.  [NO]  WORLD 

[Disallows] /allows  the  process  to  control  all  other  processes  in 
the  system. 
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ACE 

ACL 

ADP 

ASCII 

AST 

CHME 

CHMK 

CHMS 

CHMU 

CLI 

CPU 

CSR 

DBR 

DCL 

DEC 

ECU 

EPL 

lEC 

I  PAR 

I  PR 

JIB 

LDPCTX 

MFPR 


ACRONYMS 

Access  Control  List  Entry 
Access  Control  List 
Automatic  Data  Processing 

American  Standard  Code  for  Information  Interchange 

Asynchronous  System  Trap 

Change_Mode_To_Executive  instruction 

Change_Mode_To_Kernel  instruction 

Change_Mode_To_Supervisor  instruction 

Change_Mode_To_User  instruction 

Command  Langauge  Interpreter 

Central  Processing  Unit 

Control  and  Status  Register 

Data  Buffer  Register 

Digital  Command  Language 

Digital  Equipment  Corporation 

Error  Correction  Code 

Evaluated  Products  List 

Interrupt  Exception  Conditions 

Initial  Product  Assessment  Report 

Internal  Processor  Register 

Joh  Information  Block 

Load_Process_Context  instruction 

Move_From_Processor_Register  instruction 
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MTPR 

NCSC 

CDS -2 

OPCOM 

PO,  PI 

PC 

PCB 

PDP 

PHD 

PID 

PROBER 

PROBEW 

PSL 

PSW 

PTE 

REI 

RMS 

SO,  SI 

SVPCTX 

TCB 

UAF 

UETP 

UIC 

VAX 

VMS 


Move_To_Processor_Register  instruction 

National  Computer  Security  Center 

On-Disk  Structure  Level  2 

Operator  Communication  Manager 

Process  Space 

Program  Counter 

Process  Control  Block 

Programmable  Data  Processor 

Process  Header 

Process  Identification 

Probe_Read  instruction 

Probe_Write  instruction 

Processor  Status  Longword 

Processor  Status  Word 

Page  Table  Entry 

Return_From_Execption_Or_Interrupt  instruction 
Record  Management  Services 
System  Space 

Save_Process_Context  instruction 
Trusted  Computing  Base 
User  Authorization  File 
User  Environment  Test  Package 
User  Identification  Code 
Virtual  Address  extension 
Virtual  Memory  System 
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